Data and artificial intelligence create value only in a specific operating context. This data and AI FAQ explains how to move from an attractive model demonstration to a governed system that people can use and challenge. The essential unit is not the algorithm; it is a decision or task, its data, affected people, human authority, controls and observed outcomes over time.
Use this FAQ with the data and AI practical guide, the data and AI implementation checklist and the data analytics and AI guide. Laws vary by role, use and jurisdiction. The EU AI Act uses a risk-based structure and phased application; obtain current legal advice instead of inferring obligations from a technology label.
Which data and AI use cases should be prioritized?
Prioritize a frequent, consequential task with an accountable owner, measurable baseline and realistic intervention. Document who receives the output, what action changes, the cost of false positives and negatives, and the non-AI alternative. Bounded assistance such as classification, retrieval or draft generation is often easier to supervise than autonomous action. Exclude uses whose data basis, authority or harm cannot be governed.
Run an impact assessment before procurement or training. Identify affected groups, rights, safety, privacy, security, labor and environmental considerations, foreseeable misuse and recourse. NIST AI RMF organizes work through Govern, Map, Measure and Manage. Mapping the context first prevents a benchmark score from becoming the sole basis for a decision it was never designed to support.
| Use-case factor | Question | Evidence | Escalation trigger |
|---|---|---|---|
| Outcome | What improves for whom? | Baseline and target | No accountable benefit |
| Consequence | What can a wrong output cause? | Impact and failure analysis | Rights, safety or material financial harm |
| Oversight | Can a person review and intervene? | Workflow and authority test | Review is nominal or overloaded |
| Fallback | Can work continue safely? | Manual or deterministic path | No recoverable alternative |
What does data readiness for AI mean?
Data is ready when it is lawful and appropriate for the intended use, sufficiently representative, documented, traceable and maintainable. Record source, collection context, consent or legal basis where relevant, population, time period, labels, transformations, known gaps and prohibited uses. Split data to avoid leakage and preserve a representative evaluation set. More rows do not repair biased measurement or a label that poorly represents the outcome.
Set quality rules for the task: completeness, validity, timeliness, duplicates, class balance, drift and linkage confidence. Analyze performance across meaningful cohorts and difficult conditions. Protect sensitive attributes used for fairness evaluation through restricted access and purpose controls. The NIST Privacy Framework helps teams assess privacy risk created by processing, not merely whether a database is encrypted.
How should an AI system be evaluated before release?
Build evaluation from the harm and outcome model. Select task metrics and thresholds that reflect asymmetric errors, calibration and abstention. Test representative, rare, boundary, missing-data, multilingual and adversarial cases. For generative systems, assess factual support, instruction following, harmful content, privacy leakage, tool use and citation quality. Human evaluation needs a rubric, trained reviewers and agreement analysis.
Evaluate the whole workflow. Measure whether reviewers detect errors, whether confidence is understandable, whether automation bias appears and whether fallback works. A human in the loop is effective only when the person has evidence, time, authority and a recorded override route. Test accessibility and the ability of affected people to understand, contest or correct important outcomes.
| Evaluation layer | Example test | Release evidence | Production signal |
|---|---|---|---|
| Data | Coverage and leakage | Versioned profile | Drift and missingness |
| Model | Cohort errors and calibration | Threshold rationale | Error and abstention |
| Workflow | Reviewer challenge and override | Scenario results | Override and correction |
| Outcome | Decision quality and harm | Pilot comparison | Benefit and adverse events |
Who governs data and AI systems?
Assign a business owner for the outcome, data owners for sources, a technical owner for the system and named privacy, security, legal and risk reviewers. A cross-functional governance body sets policy, risk tiers, prohibited uses and escalation. Maintain an inventory with purpose, owner, model and data versions, suppliers, affected population, controls, evaluation, approvals and monitoring. ISO/IEC 42001 provides requirements for establishing and continually improving an AI management system.
Third-party models do not transfer accountability. Contract for data use, retention, security, service changes, evaluation access, incident notice, intellectual property, geographic processing and exit. Record model and prompt configuration. Reassess material supplier updates before broad release. Keep a route to disable the system, move to fallback and preserve the evidence needed to investigate outputs.
What must be monitored after deployment?
Monitor inputs, drift, data quality, output distribution, task performance, latency, cost, overrides, complaints, security events and business outcomes. Segment where impact differs. Define thresholds, owners and actions before launch. Some ground truth arrives late, so use leading indicators without pretending they prove final quality. Sample outputs for review and maintain a path for users to report errors.
Create a release record naming use, population, model and data versions, prompts or rules, evaluation, thresholds, limitations, owners, suppliers, fallback and monitoring. Link every exception to an approver and expiry. Operations can then determine which logic produced a challenged output and whether later changes require revalidation.
Red-team foreseeable misuse at system level: indirect prompt injection, malicious documents, tool overreach, extraction attempts, fabricated citations, identity confusion and repeated evasion. Include business abuse such as using an assistive score for an unapproved employment or pricing decision. Technical access and policy monitoring must reinforce each other.
Document the non-AI comparator throughout operation. Compare quality, time, cost and harm against the prior or deterministic path, not an imagined perfect baseline. If demand or policy changes, redesign evaluation. Continued use should be justified by current evidence, not the original pilot.
For delayed outcomes, preserve links among predictions, reviewer actions and eventual results while enforcing privacy and retention. Analyze where people overrode correctly and where they accepted errors. This supports recalibration and honest measurement of combined human-system performance.
Give affected people and workers a simple route to report unexpected impact without understanding the model. Triage with product and risk owners, preserve evidence and communicate outcomes. Complaints are monitoring and recourse signals, not merely support tickets.
Revalidate when purpose, population, source data, model, prompt, tools, policy or threat environment changes. Conduct incident reviews that connect harm to data, model, interface, workflow and incentives. OECD AI principles emphasize robustness, security and safety throughout the lifecycle and mechanisms to override, repair or decommission systems. Retirement must include access removal, retention or deletion, downstream communication and record preservation.
Evaluate an AI assistant with production-shaped evidence
- For a support drafting assistant, define eligible queues, languages, sensitive categories and prohibited actions. Build a lawful representative set with contradictory history, attachments, policy changes, vulnerable customers, prompt injection and escalation cases.
- Run shadow evaluation, then a bounded pilot where every draft is reviewed. Measure correction effort, resolution, repeat contact and policy errors as well as time. Stop on privacy leakage, invented policy, unsafe advice or reviewer overload.
- Contract for model-change notice, training-data use, retention, incident notice, security, availability and export. Preserve configuration and prompts. Material supplier changes require affected evaluation before expansion; keep a non-AI fallback.
- Review samples, overrides, complaints, drift, cost and outcomes monthly. Narrow eligibility, improve retrieval, retrain, adjust or suspend. Sending messages or recommending compensation is new authority requiring a fresh impact decision.
- Test whether agents understand source citations, limitations and confidence under realistic time pressure. A control that works only when reviewers have unlimited time is not a production control.
- Verify correction and recourse. When an affected customer challenges an output, staff should locate the source evidence, amend wrong data where appropriate and prevent an unresolved error from silently influencing later interactions.
Key takeaways
- Select AI from an owned task, measurable outcome and explicit harm analysis.
- Document data provenance, fitness, representation and permitted use.
- Evaluate the model, human workflow, fallback and real outcome together.
- Inventory systems and assign business, data, technical and risk authority.
- Monitor changing context and preserve the ability to override, repair or retire.
Frequently asked questions
Does every AI output need an explanation?
The form and depth depend on context and consequence. Users may need sources, factors, confidence, limitations and a challenge route. A technical feature-importance chart may not be meaningful. Design explanations for the person and decision, then test comprehension.
How long should an AI pilot run?
Long enough to observe representative demand, cohorts, exceptions and delayed outcomes. Define evidence and stopping conditions first. A shadow mode can test recommendations without executing them, but it must reproduce the information and timing of real work.
Is buying AI safer than building it?
Not inherently. A supplier may offer mature controls and broad testing, but customers still govern the use case, data, integration and human workflow. Verify evidence, contractual controls, change management and exit. Build-versus-buy does not change responsibility to affected people.
Create a release record naming use, population, model and data versions, prompts or rules, evaluation set, thresholds, known limitations, owners, suppliers, fallback and monitoring. Link every material exception to an approver and expiry. Operations can then determine which logic produced a challenged output and whether later changes require revalidation.
Red-team foreseeable misuse at system level: indirect prompt injection, malicious documents, tool overreach, extraction, fabricated citations, identity confusion and repeated evasion. Include business abuse such as using an assistive score for an unapproved employment or pricing decision. Technical access control and policy monitoring must reinforce each other.
Measure environmental and financial operation where material: inference volume, latency, compute cost, repeated retries and human correction. Optimize only after protecting outcome and safety. A cheaper model that increases rework or an accurate model that cannot meet the decision deadline may be the wrong system choice.
Prepare retirement and supplier exit before launch. Export necessary records, preserve decision evidence, revoke credentials, remove integrations and communicate downstream. Confirm retained data follows policy and cached outputs are no longer used. Retirement is a controlled lifecycle action, not simply disabling the interface.
Establish a route for workers and affected people to report unexpected impact without needing to understand the model. Triage reports with product and risk owners, preserve relevant evidence and communicate outcomes. Complaints are monitoring signals and potential recourse events, not merely support tickets to close.
Conclusion
Responsible data and AI delivery is concrete operating work. Frame the decision, prepare fit data, test consequential failures, give people real authority and monitor the live context. Governance then becomes the mechanism that allows useful systems to scale while weak or harmful ones are corrected or stopped.