AI recognition is a model inside a larger control system
A confident label can fail for an ordinary reason: a card is covered, a camera has moved or the model has never seen that layout. Its score does not explain which condition applies. Trace each crop through model version, review and final use so a high prediction score cannot quietly become the authoritative game result.
Image processing and machine learning can work together. Calibrated geometry can define a table area, a detector locate cards, a classifier read symbols and rules check the sequence. One end-to-end network may remove manual stages, but failure analysis becomes harder if it exposes no intermediate evidence.
For regulated products, do not let a model decide customer outcomes or eligibility without a documented, tested policy. New Zealand's online-casino standards assign duties to the platform, including rules, logs and random-outcome integrity. A vendor's model does not shift those duties to its supplier.
Pick a model task that can be evaluated
“Monitor the table with AI” cannot be evaluated as written. Name the event and the error consequence. A stopped card feed can be checked against stream-health labels; reading a partly covered rank needs separate examples and human review. Inferring gambling problems from facial expression is far more intrusive, weakly justified and high risk for privacy.
| Task | Model output | Decision boundary |
|---|---|---|
| Object detection | Class, location and confidence for a visible card or chip. | Candidate observation only; game rules validate the event. |
| Classification | Rank, suit, denomination or table region. | Route low-confidence or conflicting labels for review. |
| Tracking | Object identity and movement across frames. | Do not infer a legal wager from motion without a rule and service event. |
| Image quality | Blur, obstruction, glare or missing-frame status. | Alert an operator; preserve game state from the trusted platform. |
| Biometric identification | Match or category about a person. | Separate legal assessment, necessity test, safeguards and human accountability. |
Training data must represent the operating scene
Training examples should reflect camera, table, deck, lighting, compression and working practices. Clean catalogue images may not represent live footage with overlapping cards or worn chip marks. Label conditions as carefully as object classes. Split by session, table or camera to prevent near-duplicate frames entering both train and test sets.
For each dataset, track its source, legal basis, collection date, purpose, annotation process, exclusions and retention limit. Keep examples of ambiguous frames in the label guide. Have multiple reviewers label important samples and log disagreement. Preserve the first prediction if production staff correct it; do not reuse incident footage for unrelated training without notice.
Review who appears in training and evaluation data, which groups risk misclassification and the consequences of an error. Document whether a person can challenge a flag and who handles the review. Aggregate accuracy may conceal serious errors tied to one camera, lighting condition or population.
Confidence is useful only when it is calibrated
A model score can resemble certainty without being a dependable probability. Test calibration on the deployment population: for each confidence band, measure the share of correct predictions. Set thresholds by class and condition. Where a false card value is costly, route more cases to review instead of choosing a cutoff solely for total accuracy.
Allow three outputs: accepted, uncertain, and invalid or missing input. A model forced to choose a label will turn blur and occlusion into confident guesses. Let it abstain, and show the crop, competing labels and image quality so a reviewer can repeat the view, correct the table record or pause monitoring.
- Report precision, recall and calibration per class, table and camera condition.
- Keep false-positive and missed-event costs separate.
- Use a holdout set that represents new sessions and equipment changes.
- Test the model's abstention behaviour on blur, occlusion and unfamiliar objects.
- Record model version and threshold with every production inference.
Guard against drift and unsafe updates
A camera replacement, new felt, deck, codec or lighting setup can shift model performance. Watch input quality and prediction distributions. A rise in one card class may reflect normal game mix or sensor failure; it is not proof of misconduct. Check setup and labels before changing the model.
Release models in stages. Run the candidate beside the live version on identical input, then review disagreements, condition-specific errors, inference time and downstream impact. Keep a rollback route to the prior model and thresholds. Retain approvals, evaluation-set version, data lineage and limitations.
An update must not quietly change player-facing game behaviour. Moving from a monitoring suggestion to an account action changes the product and regulatory scope and requires separate review. Show reviewers the evidence that triggered action and the policy applied.
Keep the model away from protected game logic
Where possible, keep vision behind a read-only service boundary. Send observation, timestamp, table ID, confidence and evidence pointer to review or reconciliation. Withhold direct write access to RNG, settled outcomes, payment ledger and self-exclusion. Restrict model credentials and log every read and action.
Turn disagreement between model and game service into a review task. Store both events with the resolution, and never let the model overwrite the original game record. For a physical live table, specify the authoritative event source under game rules before an incident occurs.
If a model processes face, voice or behaviour to verify, identify or categorise someone, assess the Biometric Processing Privacy Code before launch. Object detection serves a different purpose, while identifiable video may still be personal information. Do not group both scopes under a catch-all analytics label.
Make human review operational
Oversight needs adequate time, authority and evidence. Cap the queue and set a maximum age for unresolved cases. Show the original frames, camera condition, model output and game state; record whether the reviewer accepted, rejected, repeated or escalated the observation. Corrections need a route that does not silently retrain production.
Review workflow for a disputed visual event
- 1. Locate Reviewer action:Open the exact game round and camera sequence.System record:Case ID, requested time range and source video IDs.
- 2. Compare Reviewer action:Inspect crop, full frame, game event and model version.System record:Evidence viewed and any missing or delayed source.
- 3. Resolve Reviewer action:Accept the observation, mark it uncertain or escalate.System record:Decision, reason, reviewer and timestamp.
- 4. Prevent recurrence Reviewer action:Flag a camera, label, threshold or model issue for owners.System record:Linked engineering ticket and closure evidence.
Score the feature by its actual benefit
Measure resolution time for real discrepancies, missed and false alerts, reviewer agreement, camera-failure recovery and manual rework. Include customer-impact checks such as incorrect settlement or account action. Alert volume, confidence and automation share alone cannot show improvement; automation may rise as errors and review costs also increase.
A result for one deck or internally collected video does not prove performance in a different studio. Record the population, camera, resolution, event definition, sample size and threshold. If the figure cannot be reproduced from retained evaluation data, do not present it as a general capability.
Keep the evaluation set, threshold, camera profile and reviewer route with each deployed model. When one changes, rerun prior misclassification cases and verify that fallback still reaches a human.