Why one global AI compliance checklist fails

Enterprise AI risk governance identifies where an AI system is used, which rules govern that use, who must act, and what evidence supports the resulting compliance decision. A company operating in several countries can maintain shared policies, tests, and monitoring. It cannot assume one risk rating or one approval satisfies every law. Obligations depend on the technology’s function, the legal entities involved, where people or outputs are affected, and whether an organization develops, supplies, or deploys the system. The useful unit of governance is therefore a specific AI use in a defined operating context linked to applicable requirements, operating controls, decision owners, and change triggers.

An employment screening tool illustrates the problem. In the EU, its intended purpose may place it in an Annex III high-risk category. In New York City, the question is whether it meets the local definition of an automated employment decision tool and is used for a covered decision. In India, personal-data processing may engage a separate, phased privacy regime. These are different legal tests applied to a similar business activity. ^{[3, 4, 5, 6, 9]}

The practical challenge is to keep those differences visible while avoiding three disconnected governance programs. A shared testing process may support more than one obligation; each obligation still needs an identified owner, evidence, and a reasoned applicability determination.

Which AI laws and standards matter across jurisdictions?

The most consequential distinction is between law that applies to a particular activity and a framework an enterprise chooses to use. A comparison should record the applicable instrument, affected actor, trigger, implementation date, and source—not an undifferentiated label such as “AI compliant.”

The EU AI Act: different duties start on different dates

The AI Act entered into force in August 2024 and applies in stages. Prohibited-practice and AI-literacy provisions began applying in February 2025; general-purpose AI model provisions followed in August 2025. Transparency rules under Article 50 generally began applying in August 2026. After Regulation (EU) 2026/1744, the core Chapter III high-risk requirements for Annex III systems are scheduled for 2 December 2027; the corresponding rules for Annex I regulated products are scheduled for 2 August 2028. The amended calendar does not suspend other provisions already in force. ^{[1, 2]}

Employment systems deserve a closer look, but the presence of AI in HR does not settle classification. Annex III identifies relevant recruitment and worker-management purposes. Article 6 also establishes qualification rules and exceptions, which must be examined against the system’s intended use and influence on decisions. The enterprise’s internal “medium risk” label cannot override the statutory classification. ^{[4, 5]}

The U.S.: activity-specific requirements

The United States has no single comprehensive federal AI statute governing every private-sector deployment. Local and state requirements should be assessed alongside employment, consumer-protection, anti-discrimination, privacy, and sectoral rules that already apply. New York City Local Law 144 prohibits covered employers and employment agencies from using an automated employment decision tool unless an independent bias audit has been performed within the required period, audit information is publicly available, and specified notices have been given. DCWP began enforcement on 5 July 2023. ^{[6, 7]}

Colorado’s 2026 legislation reworked its earlier AI law into automated decision-making technology provisions for consequential decisions, with a 1 January 2027 effective date. Its statutory terms and regulatory development differ from New York City’s AEDT regime; a generic “U.S. AI compliance” field would conceal both distinctions. ^[8]

India and China: different regulatory objects

India’s Digital Personal Data Protection Act is about qualifying personal-data processing, rather than classifying all AI systems by risk. Final DPDP Rules were notified on 13 November 2025. Selected institutional provisions began immediately; others were scheduled one year later, and much of the core processing regime becomes operative eighteen months after notification, in May 2027. An organization should record which provision applies and when rather than treating the whole Act as fully operational today. ^{[9, 10]}

China’s AI-generated-content labeling measures apply to specified service providers and content activities. Effective since 1 September 2025, they address visible indications and metadata-based labeling for covered AI-generated content. An internal recruitment scoring system and a public synthetic-content service should not be assigned the same China-specific obligations merely because both use AI. ^[11]

Determine applicability before selecting controls

Many compliance inventories begin with the question “Which framework are we using?” The more useful starting point is: What precisely is this organization doing, for whom, and under which legal role? A model can sit inside several products and workflows. The same supplier may be a provider in one arrangement and a customer or deployer in another. A regulation may cover a business location, an affected person, an offered service, or use of an output rather than the physical location of the server.

For each material AI use, record a compact set of facts: the responsible legal entity, product or workflow, AI function and intended purpose, provider and deployer relationships, operating locations, affected populations, data categories, and downstream decisions. Add the current version and significant third-party dependencies only where they alter those facts or the applicable rule.

Use and role

AI-assisted applicant screening, operated by a named employer using a third-party service. Determine which organization supplies the system and which uses its outputs.

Legal trigger

Identify each instrument’s operative test: Annex III employment use, NYC covered AEDT use, or covered Indian digital personal-data processing.

Decision

Record “applies,” “does not apply,” or “requires resolution,” supported by facts and the relevant provisions. Avoid unexplained traffic-light ratings.

Time and scope

Capture commencement date, affected countries and populations, assessment version, responsible reviewer, and the next event that could change the result.

An out-of-scope decision warrants a reason. A law may not apply because the tool has a different function, the organization does not undertake the regulated activity, or a statutory exception is established. The record should state the facts, not just “N/A.” An uncertain determination should be assigned for resolution before a consequential launch decision.

This approach also avoids a common error in EU AI Act discussions: a non-EU company is not automatically outside the regulation. Article 2 reaches certain providers and deployers outside the EU, including cases involving AI-system outputs used in the Union. Applicability still requires the specific statutory test. ^[3]

Translate overlapping obligations into shared controls

Once applicability has been established, the enterprise can reconcile requirements. Start with the precise legal duty, not with the name of a convenient internal control. Then ask which activities could meet that duty, what evidence proves the activities occurred, and which features remain jurisdiction-specific.

A common AI assessment process may generate records about intended use, data, performance testing, human decision authority, and exceptions. That is efficient because teams work from one managed evidence base. But a common assessment does not erase the legal purpose of each obligation: an EU provider’s technical documentation, a New York City independent bias audit, and an Indian personal-data notice are not interchangeable deliverables.

Consider candidate notification. A global recruitment workflow can share a central template, publication workflow, and language review. It must still meet the particular content, timing, audience, and delivery rules of each jurisdiction. An employer using an NYC-covered AEDT may need the specified advance notices and public audit information. A different disclosure requirement elsewhere may ask for distinct content or apply at another stage. One communications team can operate both processes; one generic “AI is used” sentence may satisfy neither. ^{[6, 7]}

For technical controls, commonality is more plausible. Data-quality checks, model evaluations, access-control logs, human escalation records, and change approvals may support several requirements. The record should indicate which tests were performed, to what population and period they apply, and whether any regulator requires a different scope or an independent assessor. A favorable vendor report cannot substitute for a particular local test solely because both address fairness.

This is where organizational scale creates both opportunity and risk. Centralization makes records easier to maintain. It can also conceal a gap when the same approval is relabeled as proof of several distinct duties. The remedy is a traceable requirement-to-control relationship, not duplicate committees.

Where NIST AI RMF and ISO/IEC 42001 fit

NIST AI RMF 1.0 is a voluntary framework organized around Govern, Map, Measure, and Manage. It helps teams establish ownership, understand use context, evaluate risk, and act on findings. NIST’s 2024 generative AI profile expands the risk discussion for generative systems; the RMF 1.0 is under revision in 2026. These materials inform an enterprise control design but do not determine whether a particular AI Act article or city law applies. ^{[12, 13]}

ISO/IEC 42001:2023 specifies requirements for an organizational AI management system. ISO/IEC 42005:2025 offers guidance for AI system impact assessment. Both can support a consistent process across businesses and countries. A management-system certificate concerns the scope of the certified system; it does not certify that every deployed AI product complies with every applicable law or that its predictions are accurate. ^{[14, 15]}

For detailed documentation and risk-treatment records, see the InfoSecured.ai ISO 42001 documentation guide. For third-party dependencies, see the supplier evidence and control analysis. The task here is different: translating binding requirements into accountable operating practices without flattening legal differences.

Worked example: one recruitment system, three jurisdictions

A multinational employer is introducing a purchased AI service that ranks applicants and supplies a shortlist to human recruiters. The scenario is fictional. The company recruits for roles in Germany, New York City, and India. It has one global procurement agreement and plans to use the same model family, with local data and hiring workflows.

Germany: the EU employment classification

The German hiring workflow uses AI outputs to evaluate and filter applicants. That intended purpose is within the employment category described by Annex III. The employer must determine its role under the AI Act, assess the Article 6 classification rules and relevant exceptions, and record which obligations are already applicable and which will apply when the Annex III high-risk requirements begin on 2 December 2027. A prior vendor classification should be reviewed against what the employer actually does with the system. ^{[1, 2, 4, 5]}

Suppose procurement supplies a statement that the tool was evaluated on a global dataset. That record may help identify the vendor’s testing methods. It does not establish performance for German-language applicants or the real hiring workflow. The employer can require the supplier’s instructions and intended-use constraints, test locally relevant cases, identify authorized human reviewers, and document how a decision can be challenged or overridden. The evidence should be available when the applicable obligations become enforceable; the revised high-risk deadline is not a reason to ignore requirements already in force.

New York City: a specific audit and notice regime

The New York team uses the service to substantially assist in screening candidates. The compliance owner first tests the tool and its use against the city’s definition of an AEDT. If the use is covered, Local Law 144 requires a bias audit by an independent auditor within one year before use, a publicly available summary of required results, and the prescribed notices. This is a legal obligation already in effect. It is not satisfied merely by the company’s own global fairness review. ^{[6, 7]}

The global assessment group can still supply data descriptions, model details, and candidate-flow documentation to the independent auditor. NYC-specific evidence remains distinct: dated audit output, the required published information, and proof that notices were issued appropriately. An internal control record links these items to the local hiring entity and live version of the process.

India: personal-data processing and commencement

The Indian hiring team receives applications through the same recruiting portal. The relevant starting question is whether the processing is covered by India’s DPDP Act and Rules—not whether the screening model falls into an EU-style high-risk tier. The compliance owner identifies the data fiduciary and applicable processing activities, then aligns implementation with the Act’s notified commencement schedule. On 13 November 2026, the major processing duties scheduled for eighteen months after the 2025 notification have not yet commenced; preparation and other currently effective legal duties remain separate questions. ^{[9, 10]}

Rather than reproduce an EU AI transparency notice, the team maps the Indian personal-data requirements to the recruitment privacy flow. It determines what notice, processing basis, rights mechanisms, retention, security measures, and service-provider arrangements are required when the applicable provisions commence. If business practice changes before then—for example, data are reused to train a separate model—the applicability record must be revisited.

What the company can share

Across the three operations, the company can maintain one record of the supplier, approved uses, versions, data-flow inventory, assessment results, access and change controls, and human review arrangements. Teams can run common tests when the test design and relevant population support the different decisions. The company should not create three identical control programs when one suitably designed control can serve them.

The local compliance record remains different. EU classification analysis and high-risk readiness, NYC independent audit and candidate-notice evidence, and India’s phased data-protection requirements each need their own applicability decision and proof. The practical output is therefore one managed system with multiple legally grounded decisions, not a universal compliance certificate.

Maintain evidence from obligation to operating control

Regulatory mapping is useful only when the resulting control can be located and tested. An obligation register containing a regulation name and a green status gives management little basis for challenge. A stronger record links the rule to the operational activity, source evidence, accountable decision, and conditions under which the assertion would no longer hold.

Each record should also carry the exact legal provision, applicability rationale, status, responsible legal entity, assessment date, and approved exception if one exists. For international programs, distinguish the design of a control from evidence that the control actually operated in the period claimed. A policy can establish responsibility; a completed audit, access log, or notice-delivery record demonstrates a different proposition.

Evidence frequently moves between business owners, compliance, model validation, and internal audit. Before relying on another review, the recipient needs to understand what it tested and what it did not. CEDAR-3L addresses that cross-line evidence-reliance question in depth. Here, the immediate requirement is simpler: a regulator-specific claim must lead to material that can substantiate it.

Deutsche Telekom offers a disclosed organizational example. It describes a cross-segment EU AI Act team, an EU-wide review for prohibited AI applications, and integration of digital ethics checks into existing privacy and security assessments. Its published approach illustrates how a central governance process can direct local AI use toward relevant requirements. These are the company’s reported arrangements, rather than independent proof of every system’s effectiveness. ^[16]

Keep regulatory decisions current when laws and AI uses change

A dated applicability record becomes unreliable when its underlying assumptions change. Monitoring legislation alone is insufficient: the same rule may attach to a new business activity, and a supplier update can change how an established system influences people.

Assign one owner for legal monitoring and an operating owner for each consequential AI use. Legal and compliance teams watch amendments, effective dates, regulatory guidance, and enforcement interpretation. Business and technical teams report changes to use, models, suppliers, processing purposes, populations, integrations, and human review. A shared change queue connects those signals to the relevant applicability records.

A practical reassessment asks four questions: What fact or rule changed? Which existing classification or legal duty could be affected? Which control and evidence now need updating? Who can authorize continued operation, restricted operation, or a pause? Record the answer, not a generic declaration that the system was “reviewed.”

Consider a recruitment tool originally used only to organize interview notes. Management later enables automated candidate rankings that influence selection. That may change its legal classification even when the vendor and contract remain unchanged. Conversely, a minor interface change that does not alter the legally relevant operation may justify a documented no-change decision rather than a full re-audit. The scope of reassessment should follow material changes in the statutory facts and actual risk.

Dates should be treated as governed data. A control designed against an obsolete EU 2026 high-risk deadline can cause unnecessary work or obscure obligations already effective. The same is true of an Indian compliance calendar that treats rules notified in 2025 as though every operational provision commenced that day. A change register should identify the source instrument and effective date, then show which internal decisions were revised. ^{[1, 2, 9, 10]}

What executives and auditors should examine

Management reporting should distinguish the number of systems inventoried from the number of legal questions actually resolved. A large inventory is useful for coverage; it does not prove that a regulated use has been correctly classified. Likewise, a common control catalogue is valuable only when local obligations can be traced through it.

Five questions expose the quality of the program without requiring executives to read every regulation:

1. Coverage: Which consequential AI uses lack a documented jurisdiction and role assessment?
2. Interpretation: Which applicability decisions remain unresolved or depend on assumptions requiring specialist review?
3. Control fit: Where has the organization reused one control for several rules, and what distinct local requirements remain?
4. Evidence: Which current compliance claims cannot be traced to operating records or independently required assessments?
5. Change: Which forthcoming dates, new deployments, or supplier changes could reopen an earlier decision?

Internal audit can test the completeness of intake, the quality of classification decisions, the operation of shared controls, and the consistency of exception handling. Compliance and business management retain the responsibility to interpret applicable obligations, act on deficiencies, and accept or restrict operational risk within their authorities. An assurance report should be precise about the period, legal requirements, and systems it actually examined.

The aim is an enterprise process that can answer a narrow question without assembling an ad hoc project: for this AI use, in this jurisdiction, under this role and version, what applies, what has been done, and what record supports the answer?

Frequently asked questions