AI Compliance Questions to Ask Before You Hire an Agency

Compliance is not a feature an agency adds at the end.

This is not legal advice. It is a diligence list for buyers working with their own counsel, compliance team, security team, data owners, and business leaders. Use it to find unclear ownership and missing evidence before those gaps become launch problems.

Who owns the compliance decision?

An agency may help map the system, implement controls, and prepare documentation. It should not make your organization's final legal or regulatory determination. Name the internal decision owner and the reviewers who must approve the use case before the scope is signed.

Put these names in the project plan:

The business owner who defines the purpose and acceptable outcome.
The data owners who approve each source, transfer, retention period, and access role.
The legal, compliance, security, or risk reviewers who decide which requirements apply.
The agency and internal operators responsible for controls, evidence, monitoring, and incident response.

Ask where the agency's responsibility ends at handoff. A document labeled “compliance” does not settle who approved the system or who answers for it after launch.

What data enters the system?

Request a data-flow map before approving architecture. NIST's generative AI profile describes privacy risks from unauthorized use, disclosure, leakage, and inference of sensitive data. The buyer question is what information reaches each part of your actual workflow.

Which fields come from customers, employees, partners, public sources, and internal systems?
What is sent to the agency, model provider, hosting provider, logging service, and analytics tools?
Where are prompts, outputs, files, embeddings, feedback, and traces stored, and for how long?
Which roles can view, export, correct, or delete each copy?
What data can be excluded, masked, aggregated, or processed without a model call?

Have the map cover testing and support as well as production. Debug logs and copied test files can carry the same sensitive information as the main application.

Which decisions affect people?

Trace where the system screens, ranks, recommends, approves, denies, prices, or communicates something that affects a person. Mark what the model produces, what a human reviews, what enters another system, and how someone can challenge an outcome.

The European Commission describes a risk-based AI Act framework and lists certain uses in employment, education, access to essential services, law enforcement, and other areas as high-risk. That page is a useful prompt for scrutiny, not a classification of your project or a substitute for advice about applicability.

Who could gain, lose, wait, pay, or be investigated because of the output?
Does a human have enough context and authority to reject the recommendation?
How are errors, inconsistent treatment, and appeals recorded and reviewed?
What happens when the system has too little evidence or produces an uncertain answer?

What evidence will exist after launch?

Ask for named artifacts, not a promise that the system will be auditable. The Commission's overview describes documentation, logging, human oversight, robustness, cybersecurity, and accuracy obligations for high-risk systems. NIST recommends documented testing, monitoring, incident response, and change management across the lifecycle.

The approved purpose, prohibited uses, data map, system versions, and assigned owners.
Test cases, representative conditions, known limits, acceptance criteria, and approval records.
Logs that connect inputs, model and prompt versions, human reviews, tool calls, and outcomes.
Issue, appeal, incident, override, and corrective-action records with retention rules.
A handoff package your internal team can access without the agency's private account or memory.

If the work includes customer-facing documentation or public claims, assign a reviewer for those too. Google's helpful-content guidance emphasizes clear sourcing, factual accuracy, and material written to help an intended audience; it does not establish whether an AI system complies with a law.

What changes after deployment?

A launch approval covers a specific system in a specific context. Models, prompts, connected tools, provider policies, data, and business rules can change. Decide which changes are routine, which require new tests, and which return to the original reviewers.

Who monitors performance, incidents, complaints, access, and changes in the use case?
What model, prompt, data, tool, or policy changes trigger re-evaluation or approval?
How are provider changes and agency maintenance work documented before release?
Who can pause the system, preserve evidence, notify affected teams, and decide whether to restart?
What operating work remains with your team when the agency engagement ends?

A useful proposal makes this operating model visible. If every compliance answer depends on work that will be decided after launch, the buyer still does not have a complete scope.

Looking for help with AI governance work?

Browse public AI consulting listings, then ask each agency for evidence that matches your use case. A listed service or ownership status does not verify compliance expertise.

Browse AI consulting listings