An AI tool can be approved for one business task and create a different set of obligations when the same company uses it elsewhere. A chatbot answering product questions, a recruitment assistant screening applicants and a system recommending credit decisions should not share one blanket approval.
For leaders expanding across borders, the practical answer is to document each use case, identify the markets it touches and assign controls before deployment. This AI compliance checklist turns that process into seven decisions that product, legal and operations teams can work through together.
The timing is relevant. Dinis Guarda and Businessabc.net announced a new AI Global Regulations Atlas and companion white paper on November 5, 2026. The launch announcement describes a resource covering 109 countries and jurisdictions. Its business value is as a starting point for research; organisations still need to verify which obligations apply to their own activities.
What AI compliance means for a business
AI compliance means meeting the legal and regulatory requirements that apply to how an organisation develops, purchases and uses AI. AI governance is the wider system of ownership, approval and monitoring that helps the organisation do that consistently.
A company needs both. A policy can say that employees must protect customer information, but compliance depends on whether the actual tool, contract and workflow protect it.
The European Commission describes the EU AI Act as a risk-based framework for developers and deployers. That makes the intended use of a system central to the assessment. A vendor’s general statement that its product is compliant does not settle the customer’s separate deployment questions.
A seven-step AI compliance checklist
1. Record the task and the decision it influences
Create one register entry for each materially different use, even when several teams use the same software.
Record the business purpose, affected people, inputs, outputs, tool version and responsible owner. Explain whether the output informs a person or directly triggers an action.
For example, summarising an applicant’s CV and automatically rejecting that applicant are different workflows. The register should make that difference visible before anyone assesses the legal position.
2. Map the markets and people involved
Ask where the business operates, where affected users are located and where outputs will be used. Record the location of vendors and relevant data processing as well.
Do not assume the company’s registered address answers every jurisdiction question. Give the legal reviewer a factual deployment map, rather than asking them to approve an abstract product called an AI assistant.
For initial research, the AI Global Regulations Atlas groups jurisdictions by regulatory approach and includes an exposure checker. Use its results to build a list of instruments to examine, then check the official texts, scope and current dates. An unflagged instrument is not evidence that no obligation exists.
3. Separate binding duties from policy signals
A proposed bill, voluntary framework and law already in force need different responses. Your obligations register should distinguish them explicitly.
| Status | Practical response | Record to retain |
| Binding and applicable now | Implement the required control | Scope assessment and evidence |
| Adopted with a future application date | Assign preparation work | Deadline, owner and dependencies |
| Proposed legislation | Monitor developments | Source and next review date |
| Voluntary guidance | Decide whether to adopt it | Rationale and control mapping |
This prevents two expensive errors: treating a proposal as an immediate requirement, or overlooking an existing duty because the team is waiting for a new AI law.
4. Check data handling before opening access
Ask what information can enter the tool, who can retrieve it and how long it remains available. Check whether the supplier uses submitted information for model training and whether administrators can control that setting.
Define permitted and prohibited inputs in language employees can follow. “Use responsibly” is less useful than “do not upload customer identity documents into this workspace.”
If the supplier cannot answer a material data question, restrict the pilot to approved test data while the issue is resolved.
5. Make human oversight a real action
“Human in the loop” is incomplete unless someone knows what to review and has authority to intervene.
Specify which outputs require approval, what evidence the reviewer needs and when the system must stop. Give the reviewer a route to challenge an output without having to accept it first.
For a customer-service assistant, this might mean escalating account-specific complaints to a trained employee and preventing the assistant from issuing refunds beyond its approved permissions.
6. Test failure conditions and keep evidence
Test the workflow against plausible mistakes, including missing information, ambiguous instructions and attempts to obtain restricted data. Set acceptance criteria before reviewing the results.
Keep the test date, system version, examples, findings and approval decision. NIST’s voluntary AI Risk Management Framework organises risk management around Govern, Map, Measure and Manage, with attention to risks throughout the system lifecycle. It offers a useful structure for this work; following it does not itself establish legal compliance.
7. Assign review triggers after launch
A reviewed system can change when its supplier updates a model, a new department adopts it or the business enters another market.
Name the person who monitors changes and define what requires reassessment. Include incidents, new data sources, expanded permissions and changes to applicable rules.
The approval should state its boundaries so the next team can see whether its proposed use falls inside them.
Worked example of a cross-border chatbot launch
Consider a hypothetical retailer introducing a support chatbot for customers in the UK and EU. Its initial purpose is to answer questions using approved product information.
The launch team can create a concise approval record:
- Permitted use: explain published product specifications and delivery policies.
- Restricted use: no identity verification, payment processing or independent decisions on disputes.
- Review evidence: incorrect-answer tests, access checks and a tested handover to customer support.
- Change trigger: any connection to customer accounts requires a fresh assessment.
This is a proposed operating approach, not a finding that the retailer meets every applicable rule. Its advantage is that reviewers can assess a defined workflow and ask specific questions.
What to do first
Start with one AI workflow already in use. Give it an owner, document its permissions and list the unresolved questions that could affect deployment.
Before expanding it, make sure someone can explain what it does, which obligations were assessed, what evidence supports approval and how it can be stopped. That record is more useful than a company-wide promise to use AI responsibly.
