DEV Community: Logan Foster

Read This Before You Book Your AIGP Exam

Logan Foster — Sun, 27 Sep 2026 05:03:25 +0000

Booking the AIGP exam itself is a simple process — the mistakes happen around it, not in it. Here's what's worth knowing before you hit confirm on a date.

The mechanics are straightforward: create an IAPP account, purchase the exam voucher ($649 for members, $799 for non-members), then use the code you're given to schedule through Pearson VUE, either at a physical test center or through OnVUE, Pearson's remote-proctored online option. You'll get a confirmation email with your date, time, and instructions once it's booked. None of that is where people trip up.

The first thing to check is your purchase window. Once you buy the exam, you typically have to complete it within one year — plan your study timeline against that date, not against an open-ended "someday." If you're not realistically going to be ready within that window, it's worth delaying the purchase itself rather than buying early and letting the clock run out on you.

If you're going the remote OnVUE route, time zones are a more common failure point than people expect, especially if you're scheduling from a different region than where your account or billing details are set up. Double-check the displayed appointment time against your actual local time zone before confirming — a surprising number of missed or rescheduled appointments trace back to exactly this.

Know the retake rules before you book, not after a fail. If you don't pass on your first attempt, IAPP requires a seven-day waiting period before you're eligible to retake, and you'll need to purchase another exam attempt. Building that into your mental timeline up front — rather than discovering it after a disappointing result — makes the difference between a minor setback and a scheduling scramble.

If you need any kind of testing accommodation, contact IAPP before you book, not after. Accommodation requests generally need to be arranged ahead of scheduling, and trying to sort it out after you've already picked a date and time adds friction you don't need.

Finally, think about which delivery format actually suits you. A test center gives you a controlled environment with none of the "is my webcam angle going to flag me" anxiety that comes with remote proctoring, but it requires travel and a fixed commute on exam day. OnVUE gives you flexibility and no travel, but you're responsible for a compliant testing space — a clear desk, no other people in the room, stable internet — and any environment issue can delay or interrupt your session.

For the complete pre-booking checklist, including what counts as valid ID and how to handle a reschedule if your date stops working, this guide covers it end to end.

NYC's Local Law 144 Is a Preview of Every AI Hiring Law Coming Next

Logan Foster — Thu, 24 Sep 2026 05:50:08 +0000

Local Law 144 gets talked about like a New York quirk. It isn't. It's the first fully enforced bias-audit law for AI hiring tools in the U.S., and it's the template every subsequent state law — Illinois, Colorado, New Jersey — is building from. If you work anywhere near HR tech, recruiting ops, or compliance, this is the law to actually understand, not skim.

The mechanics are simple to state and easy to get wrong in practice. If you use an automated tool — resume screening software, an AI-driven candidate ranking system, video-interview scoring — to substantially assist or replace a hiring decision for a role based in NYC, you need three things: an independent bias audit completed within the prior year, a public summary of that audit posted on your website, and advance notice to candidates at least ten business days before the tool is used.

The part employers consistently miss: jurisdiction is based on where the job is, not where the company is headquartered. A fully remote company outside New York can still be covered if it's hiring for a role a New York-based candidate fills. "We're not an NYC company" is not a defense.

The other common gap is treating the audit as a one-time checkbox. Bias audits are a snapshot — model drift and shifting applicant pools mean last year's clean audit doesn't guarantee this year's is clean too. Enforcement has also been tightening; a late-2025 city comptroller review found the agency's oversight had been inconsistent, which typically precedes stricter enforcement, not looser.

If you're building or buying an AEDT and want the plain-English rundown of what's actually required, this explainer covers the audit requirements, the notice obligations, and where employers most often get caught out.

NYC Local Law 144 Has Been In Force for Two Years. Here's What the Audits Actually Revealed.

Logan Foster — Mon, 21 Sep 2026 12:37:16 +0000

NYC Local Law 144 became effective July 5, 2023 — requiring employers and employment agencies using automated employment decision tools (AEDTs) in hiring or promotion decisions affecting NYC candidates to conduct annual independent bias audits and publish the results.

Two years of published audit results is enough to draw conclusions. Not about whether the law is working in a policy sense — that's a different debate — but about what the audits are actually finding, what the compliance landscape looks like, and what the published results tell practitioners about AI hiring tool governance more broadly.

What Two Years of Audits Shows

Adverse impact ratios are frequently above 0.8 — but not uniformly.

The most common finding across published bias audits: selection rate ratios for most demographic categories fall above the 0.8 four-fifths threshold that indicates adverse impact under EEOC Uniform Guidelines. This is the pattern vendors point to when marketing their tools as "passing" the bias audit.

What the published audits also show: variability is significant across tools, across demographic categories, and across the specific job roles being screened. Resume screening tools that show no adverse impact for white vs. Black candidates may show meaningful disparities for Hispanic candidates or for specific gender categories. The headline "passed the bias audit" often conceals within-audit variation that deserves scrutiny.

Testing methodology varies enormously across auditors.

NYC Local Law 144 specifies that audits be conducted by independent auditors but doesn't specify methodology in detail. The result: audit reports vary dramatically in what they test, how they present results, and how much information is disclosed.

Some published audits report selection rates and adverse impact ratios for five or six demographic categories with detailed confidence intervals and statistical significance assessments. Others report the same metrics for two categories without statistical analysis. Both technically satisfy the disclosure requirement — which tells you more about what the law requires than about what the tools are actually doing.

The Archuz breakdown of NYC Local Law 144 covers what a credible audit methodology should include and how to evaluate published audit results against those standards.

Intersectional analysis is almost universally absent.

Virtually no published NYC Local Law 144 audit includes intersectional analysis — testing for disparities in outcomes for Black women as a combined category, for example, rather than Black candidates and women as separate analyses. This is a significant methodological gap, because single-axis analysis can miss patterns of intersectional discrimination that don't appear when each characteristic is examined independently.

Compliance is uneven and enforcement has been selective.

A 2025 audit of employer compliance with NYC Local Law 144 found significant non-compliance: many employers using AEDTs in NYC hiring hadn't published bias audit results, and some weren't aware the requirement applied to them. Enforcement actions have been issued but don't yet reflect the full scope of non-compliance in the employer population.

What This Means for Employers

"The vendor says they passed the bias audit" is not sufficient diligence. Vendor-commissioned audits have an inherent interest alignment problem — the vendor is the client paying the auditor, and the auditor is competing for repeat business. Some vendors commission audits from multiple auditors and publish the most favorable results. Employers should review published audit results themselves rather than relying on vendor summaries.

The audit is about the tool in the specific deployment context. NYC Local Law 144 audits test the AEDT's outputs — the selection rates the tool produces in actual use. But different deployment contexts can produce different results: an AI hiring tool that shows acceptable adverse impact ratios when screening for one role category may show problematic ratios when screening for a different role. Employers should understand which roles and contexts the published audit covers.

The publication requirement creates a paper trail that plaintiffs can use. Published bias audit results that show disparities in protected categories — even above the four-fifths threshold — can be used as evidence in discrimination litigation. An employer who published an audit showing an adverse impact ratio of 0.81 for one category may find that result becomes relevant if a candidate in that category files a discrimination claim. This isn't a reason to not publish; it's a reason to understand what you're publishing.

The annual cadence matters. A bias audit from 2023 covering a tool that has been updated twice since then isn't current evidence of that tool's current behavior. Employers should confirm that the audit they're relying on covers the current version of the tool in its current deployment configuration.

The Broader Governance Lesson

NYC Local Law 144 is the most specific US employment AI disclosure requirement in force. Its experience over two years reveals something important about bias audit requirements generally: disclosure requirements without methodology standards produce wildly variable information quality.

When an employer publishes an NYC Local Law 144 audit that tests two demographic categories with no statistical significance analysis, and another publishes an audit testing eight categories with full statistical rigor, both are "compliant" with the disclosure requirement — but they're not providing equivalent governance assurance.

For governance practitioners designing AI bias audit programs beyond what NYC Local Law 144 requires: the methodology matters more than the disclosure. A rigorous internal bias assessment is more governance value than a technically compliant public disclosure that doesn't test what matters.

Further reading:

Australia Walked Away From Its AI Guardrails. What That Decision Reveals.

Logan Foster — Sat, 19 Sep 2026 08:38:11 +0000

In 2023, Australia published a set of voluntary AI Ethics Principles and initiated consultation on mandatory AI guardrails — a process that generated significant industry and public input and appeared to be building toward binding AI regulation. By 2025, the government had largely abandoned that track, replacing the mandatory guardrails approach with an updated voluntary framework and a sector-by-sector regulatory strategy.

The Australian AI regulatory retreat is one of the most instructive data points in the global AI governance landscape — not because Australia's approach is wrong, but because the reasons for the retreat illuminate the genuine tensions in AI regulation that every jurisdiction is navigating.

What Australia Was Building

The mandatory AI guardrails consultation, led by the Department of Industry, Science and Resources, proposed a set of requirements for organizations developing or deploying "high-risk AI" in Australia. The proposed guardrails were risk-based, broadly aligned with the EU AI Act's domain categories, and included transparency, accountability, human oversight, and impact assessment requirements.

The consultation attracted hundreds of submissions from industry, civil society, academia, and government agencies. By most accounts, the policy development was substantive and the proposals were taken seriously.

What happened between consultation and policy: a combination of factors that reflect real tensions rather than bad faith.

Why It Stalled

Industry opposition framed around competitiveness. The dominant industry narrative in Australia's consultation was competitiveness risk — the argument that mandatory AI regulation would disadvantage Australian companies relative to US competitors operating under lighter-touch federal guidance. This argument has more resonance in smaller economies where the competitive cost of asymmetric regulation is higher and the regulatory capacity to enforce complex rules is more limited.

Regulatory capacity constraints. Australia doesn't have a dedicated AI regulator. The existing regulatory architecture — with the OAIC handling privacy, ASIC handling financial services, TGA handling medical devices, and so on — was the proposed vehicle for sector-specific AI enforcement. The mandatory guardrails approach would have required significant uplift in regulatory capacity across multiple agencies simultaneously, which the government assessed as operationally difficult in the near term.

The "wait and see" on EU AI Act implementation. With the EU AI Act entering its implementation phase, the Australian government made a judgment that observing EU enforcement experience before committing to a similar framework was prudent. This is a defensible policy position — the EU AI Act's compliance burden is still being characterized, and jurisdictions that move second benefit from that experience.

The sector-specific alternative. Rather than a horizontal AI law, Australia committed to working through existing sector regulators to develop AI-specific guidance within their remits — similar to the UK's approach. ASIC on AI in financial services, TGA on AI in medical devices, OAIC on AI and privacy. This approach has precedent (it's working reasonably well in the UK) and is more achievable given existing regulatory capacity.

What Australia Actually Has Now

The National AI Strategy (updated 2025) and the voluntary AI Safety Standard provide the current framework. Key elements:

Voluntary AI Safety Standard. Organizations developing or deploying AI in Australia are encouraged (not required) to apply ten safety standard elements covering governance, transparency, testing, human oversight, and incident response. The standard is closely aligned with the EU AI Act's principles and the NIST AI RMF, which allows organizations with existing compliance programs to apply them without rebuilding.

Sector-specific regulatory activity. ASIC has issued guidance on AI in financial services. TGA has updated its AI as a medical device framework. The OAIC has issued AI and privacy guidance. These are advisory rather than binding in most cases, but they signal enforcement priorities.

International engagement. Australia is active in the Global Partnership on AI, the OECD's AI work, and bilateral AI governance agreements, particularly with the US and the EU. This multilateral engagement is partly compensating for the absence of domestic binding regulation — Australia is shaping international norms even while deferring domestic binding action.

What It Tells Us About Global AI Governance

Voluntary frameworks are not nothing — but they're not enough for high-risk AI. Australia's voluntary approach will produce meaningful governance improvement for organizations that engage with it seriously. It won't produce the baseline of mandatory compliance that protects individuals from organizations that don't engage voluntarily. The sectors where this gap matters most are the same ones the EU AI Act focuses on: healthcare, financial services, employment, law enforcement.

Small-to-medium economies face a structural dilemma in AI regulation. The EU can regulate unilaterally because its market is large enough to impose compliance on global companies. Australia, Canada, Singapore, and similar jurisdictions can influence global norms through voluntary frameworks and multilateral engagement, but they can't unilaterally shape the behavior of global AI companies the way the EU can. The Australia experience illustrates that dilemma clearly.

The "watch the EU and learn" strategy is rational but has costs. Second-mover advantages in regulation are real — learning from EU enforcement experience before committing is reasonable. The cost is that in the gap period, AI-related harms that binding regulation would have prevented are occurring. That tradeoff is being made explicitly or implicitly by most non-EU jurisdictions right now.

For practitioners advising organizations in APAC: the practical compliance picture in Australia is voluntary frameworks plus sector-specific guidance plus EU AI Act obligations for any EU-market operations. The EU obligations are likely to be the most operationally demanding layer and the one that effectively sets the governance floor for multinationals regardless of Australian domestic requirements.

Further reading:

South Korea's AI Basic Act Is In Force. Most Western Practitioners Have Never Heard of It.

Logan Foster — Mon, 14 Sep 2026 10:57:36 +0000

South Korea enacted the AI Basic Act in January 2025 — making it one of the first countries in the world to pass comprehensive AI legislation, alongside the EU. The law came into force in stages through 2025 and 2026, and its implications extend beyond South Korea's borders for any organization operating in or deploying AI to Korean markets.

Despite this, it receives a fraction of the practitioner attention the EU AI Act does. That gap is worth closing.

The Core Architecture

The AI Basic Act is a framework law — it establishes principles, institutional structures, and a legal foundation for more detailed regulations to follow. This is a common legislative approach in Asian jurisdictions and differs from the EU AI Act's more prescriptive, directly applicable structure.

The law establishes three foundational principles that all AI development and use must respect:

Safety — AI systems must not pose unreasonable risks to human life, physical safety, or fundamental rights.

Transparency — Individuals must be able to know when AI is affecting decisions or interactions that concern them.

Human control — AI systems must remain subject to meaningful human oversight, particularly for high-impact decisions.

These principles aren't enforceable rights on their own — they're interpretive guides that shape how the more specific obligations in the law and its implementing regulations are applied.

High-Impact AI Systems: The Operative Category

Like the EU AI Act, the Korean AI Basic Act centers its most substantive obligations on a defined category of higher-risk systems. Korea calls these "high-impact AI" — systems that have a significant effect on fundamental rights, safety, or other major interests of individuals.

The Act identifies specific domains where AI is presumed high-impact:

Employment decisions (hiring, promotion, performance evaluation, termination)
Education (admission decisions, academic assessment)
Financial services (credit scoring, insurance underwriting)
Healthcare (diagnosis, treatment recommendations)
Legal proceedings (bail, sentencing, judicial support)
Public services provided by government bodies

Organizations deploying AI in these domains must comply with the high-impact AI obligations, which include:

Pre-deployment impact assessment. Before deploying a high-impact AI system, organizations must assess the potential impact on users and affected third parties. The assessment must cover the system's purpose, the data it uses, the affected population, and the safeguards in place.

Human oversight mechanisms. High-impact AI systems must be designed and operated to allow meaningful human review of AI outputs before consequential decisions are made.

Transparency to affected individuals. Individuals must be informed when an AI system is materially influencing a decision about them — with enough information to understand the basis for the decision.

Incident reporting. When a high-impact AI system causes or nearly causes significant harm, organizations must report the incident to the newly established AI Safety Institute (AISI) of Korea.

The Korea AI Safety Institute

One of the Act's most significant institutional contributions is the establishment of the Korea AI Safety Institute — a dedicated government body with responsibility for AI safety evaluation, standards development, and technical support to other regulators.

KAISI's mandate includes evaluating AI systems for safety before they enter the Korean market, developing technical standards for AI safety and robustness testing, and maintaining an AI incident registry. It's modeled conceptually on similar bodies being established in the EU (the EU AI Office) and the UK (the AI Safety Institute that emerged from the Seoul Summit).

For organizations seeking Korean market access for AI products, KAISI engagement is the operative regulatory interaction — similar in function to EU market surveillance authority engagement under the EU AI Act.

How It Compares to the EU AI Act

Risk architecture. Both laws use a risk-based approach with a defined higher-risk category. Korea's "high-impact AI" and the EU's "high-risk AI" cover overlapping but not identical domain lists — Korea includes judicial proceedings more explicitly; the EU includes biometrics and migration more prominently.

Binding vs. framework. The EU AI Act is more directly prescriptive — organizations know from the Act's text what specific controls are required for high-risk systems. Korea's Basic Act delegates more to implementing regulations, which creates short-term uncertainty but allows faster adaptation as the technology evolves.

Conformity assessment. The EU AI Act requires formal conformity assessments for high-risk systems, with a defined methodology and in some cases third-party audit. Korea's approach is less formalized at the statutory level — the assessment requirement exists, but methodology is developed through KAISI standards rather than statutory specification.

GPAI obligations. The EU AI Act has a distinct regime for general-purpose AI model providers. Korea's Basic Act addresses foundation model developers through the high-impact framework when those models are used in high-impact contexts, but doesn't have a separate GPAI-equivalent regime at the statutory level.

Penalties. The EU AI Act's penalty structure (up to €35M or 7% of global turnover for prohibited practice violations) is more severe than Korea's current framework. Korea's penalties are significant but calibrated to domestic market scale.

What Practitioners Need to Know

For AIGP candidates: South Korea appears in the BoK v2.1's global AI regulatory landscape coverage. The key points to know are the risk-based architecture centered on high-impact AI, the domains classified as high-impact, the Korea AI Safety Institute as the primary regulatory body, and the parallel structure to (but meaningful differences from) the EU approach.

For practitioners with Korean market operations: the high-impact AI obligations are live for the domains listed above. If your organization deploys AI in hiring, credit, healthcare, or other listed domains in Korea, impact assessments and human oversight mechanisms are required — not aspirational.

For compliance leaders building global AI governance programs: the Korea AI Basic Act is further evidence that risk-based, domain-specific AI governance is converging as the global regulatory norm. Organizations that have built EU AI Act compliance infrastructure can largely extend it to Korea rather than rebuilding — the domain overlap is significant and the core control requirements are structurally similar.

Further reading:

Most AI Governance Programs Track Activity. Here's How to Track Whether They're Working.

Logan Foster — Sat, 22 Aug 2026 02:11:01 +0000

The most common failure mode in mature AI governance programs isn't bad policy — it's policy that exists but doesn't do anything.

The programs that fall into this trap share a characteristic: they measure inputs (how many policies were written, how many trainings were completed, how many systems were reviewed) rather than outcomes (whether the governance controls are actually reducing risk).

Activity metrics are not effectiveness metrics. Here's the difference, and how to build a measurement approach that actually tells you whether your program is working.

Why Activity Metrics Are Seductive and Wrong

Activity metrics feel rigorous. "We completed AI impact assessments on 100% of high-risk systems this year" is a concrete, verifiable statement. It sounds like evidence of a functioning program.

The problem is what it doesn't tell you: whether the assessments found anything, whether the findings were acted on, whether the systems are actually safer as a result of the assessments existing.

A governance program that produces completed assessments nobody reads is generating documents, not reducing risk. A training program with 98% completion rates but no behavior change is producing certificates, not capability.

The organizations with the most mature AI governance programs have moved from activity measurement to effectiveness measurement. Here's what that looks like.

The Six Metrics That Actually Matter

1. Risk finding rate and resolution rate

Track: of the AI impact assessments completed in the period, what percentage identified at least one material risk? Of the risks identified, what percentage have been resolved, mitigated, or accepted with documented rationale?

If your impact assessments are consistently finding zero issues, one of two things is true: your AI systems are genuinely low-risk, or your assessment process isn't calibrated to find real risks. The former is possible; the latter is more common.

A healthy finding rate signals that assessments are rigorous enough to surface real issues. A healthy resolution rate signals that the governance process has teeth — findings lead to action, not just documentation.

2. Assessment currency rate

Track: of AI systems currently in production, what percentage have a current impact assessment (completed within the required review cycle for their risk tier)?

This metric degrades over time as new systems are deployed, existing systems change, and review cycles pass without reassessment. A program that starts at 100% currency and drops to 60% over twelve months has a maintenance problem — either the intake process is missing new systems, or the reassessment cadence isn't being followed.

3. Human oversight failure rate

For AI systems with required human oversight steps — review before action, approval before deployment, escalation for edge cases — track how often those steps are being skipped or bypassed.

This requires logging the oversight step, not just documenting that it should exist. Organizations that don't have technical controls enforcing oversight requirements (and rely purely on process) often find significant bypass rates when they actually measure.

4. Third-party compliance rate

Track: of AI vendor contracts subject to your third-party AI requirements (incident notification, no-training-on-customer-data, audit access rights, model update notification), what percentage include the required provisions?

A governance policy that says "all AI vendor contracts must include X" is meaningful only if X is actually in the contracts. The gap between policy and contracts is one of the most common findings in AI governance audits.

5. AI incident rate and time to detection

Track AI-related incidents: outputs that caused harm, near-misses, bias complaints, security incidents involving AI systems. Both the rate (how many incidents per period, normalized by system count or transaction volume) and the detection timeline (how long between incident occurrence and detection) are meaningful.

Incident rate alone is ambiguous — a high incident rate might mean AI systems are behaving badly or might mean detection capability is good. Time to detection disambiguates: a program that detects incidents quickly is more effective than one that detects them slowly, regardless of volume.

6. Shadow AI policy bypass rate

Track: how many unauthorized AI tools are identified per period through network monitoring, help desk tickets, or employee surveys? What's the trend?

A declining trend suggests the official AI program is meeting employee needs and the bypass incentive is decreasing. A flat or increasing trend is a signal that the official program isn't keeping up with demand.

Building the Measurement Infrastructure

These metrics require instrumentation. Most of them aren't available from existing systems without deliberate design.

Assessment tracking needs to be centralized — a system of record for AI impact assessments, not a collection of individual documents. The system needs to record not just that an assessment was completed, but what it found and what was done about it.

Human oversight steps need technical controls, not just process descriptions. If the oversight step isn't logged by a system, you can't measure whether it's happening.

Vendor contract data needs to be extractable. This usually means either a contract management system with AI provision tagging or a periodic manual audit of vendor contracts against requirements.

Incident data needs a consistent intake process — a defined channel for reporting AI-related incidents, with categorization that allows analysis.

None of this is technically complex. All of it requires intentional design. The organizations that have it typically built it during the governance program implementation, not as an afterthought.

Reporting It Upward

The metric set above is designed to produce a one-page governance scorecard that's meaningful to a board or executive committee. Not the detail — the summary:

Coverage: are all high-risk systems being assessed and current?
Quality: are assessments finding real issues and resolving them?
Controls: are oversight mechanisms actually operating?
Contracts: are vendor requirements actually in contracts?
Incidents: is the program detecting and responding to issues?

A governance program that can answer these five questions with current data is demonstrably effective. One that can't is a policy exercise, not an operational program.

Further reading:

China's AI Regulation Is More Advanced Than Most Western Practitioners Realize

Logan Foster — Sun, 16 Aug 2026 02:55:14 +0000

Western AI governance discourse tends to treat the EU AI Act as the global regulatory benchmark and US state laws as the secondary reference. China's AI regulatory framework gets mentioned occasionally, usually in the context of geopolitics rather than compliance.

That framing misses something important. China has been issuing binding AI-specific regulations since 2021 — years before the EU AI Act became enforceable — and its regulatory approach is technically sophisticated in ways that practitioners working with AI internationally need to understand.

The Regulatory Architecture

China's AI governance isn't built around a single comprehensive law like the EU AI Act. It's a layered set of regulations, each targeting a specific AI application category, issued by the Cyberspace Administration of China (CAC) in coordination with other regulators.

The major instruments, in order of issuance:

Algorithm Recommendation Regulations (2022). Binding rules for platforms using algorithmic recommendation systems — essentially any platform that personalizes content, products, or information for users. Requirements include: transparency about recommendation logic, the ability for users to opt out of personalized recommendations, prohibition on using personalization to create "information cocoons" (filter bubbles), and restrictions on targeting minors with addictive content patterns.

Deep Synthesis Regulations (2022). Binding rules for generative AI used to create synthetic media — deepfakes, synthetic voice, AI-generated text presented as real. Requires disclosure labeling on synthetic content, identity verification for service providers, and prohibition on using deep synthesis to create content that damages national security, social stability, or the reputation of individuals without consent.

Generative AI Regulations (2023). The most comprehensive of the three. Applies to organizations providing generative AI services to the public in China. Requirements include: training data quality and legality compliance, content filtering to prevent prohibited outputs (a longer list than Western frameworks), security assessments before public launch for services with significant public reach, and labeling of AI-generated content.

AI-Generated Content Labeling Standards (2025). Technical standards for how AI-generated content must be labeled, including both visible (on-screen) labeling and metadata embedding. China's approach to content provenance is technically detailed and in some respects ahead of equivalent Western standards.

How It Compares to the EU Framework

Scope and application. The EU AI Act is a horizontal framework that applies across all AI use cases based on risk tier. China's approach is vertical — specific regulations for specific application types. The practical effect is that some application categories (recommendation systems, synthetic media) have more specific and operationally detailed requirements in China than the EU, while other categories have less coverage.

Security assessment requirement. China's Generative AI Regulations require a security assessment before public launch for GenAI services meeting certain thresholds. This is more prescriptive than EU AI Act conformity assessment in one specific way: it involves direct engagement with the CAC before launch, not just self-certification. The CAC reviews the assessment and must clear the service before public deployment.

Content restrictions. China's AI regulations include content prohibition lists that are longer and more specific than EU AI Act prohibited practices. They include prohibitions on content that challenges the socialist system, undermines national unity, or damages the image of national heroes — categories that have no equivalent in Western frameworks. For non-Chinese organizations, this content dimension is less directly relevant, but understanding it is important for organizations with any China-facing AI deployment.

Labeling requirements. China's AI-generated content labeling standards are technically more detailed than anything currently in force in the EU or US. The 2025 standards specify both on-screen disclosure requirements and invisible metadata embedding using standard content provenance infrastructure (similar to C2PA). For organizations building content provenance into AI systems globally, China's standards are a meaningful technical reference.

Data localization. Unlike the EU AI Act (which is primarily a system governance framework), China's AI regulations interact significantly with its data localization requirements under the Data Security Law and Personal Information Protection Law (PIPL). Training data for China-facing AI services must comply with these instruments, which creates data governance constraints that have no direct EU AI Act parallel.

What Practitioners Need to Know

For AIGP candidates: China appears in the BoK v2.1's treatment of global AI regulatory landscape. You're not expected to know China's regulations in the detail you need for EU AI Act, but you should understand that China has binding AI-specific regulations, that they predate the EU AI Act, and that the approach differs structurally (vertical, application-specific) from the EU's horizontal risk-based approach.

For compliance practitioners at organizations with China market exposure: the practical compliance requirements are real and enforced. The security assessment process, the content filtering requirements, and the labeling standards require specific implementation work. Organizations deploying GenAI services in China that haven't completed a security assessment with the CAC are in violation of binding law — not just a best practice gap.

For governance practitioners building global AI governance programs: China's framework is evidence that risk-based AI governance isn't exclusively a Western concept, but that the specific risk categories and the regulatory mechanisms differ substantially across jurisdictions. A global AI governance program needs to be jurisdiction-aware, not just EU AI Act plus US state law.

Further reading:

The AI Vendor Contract Clauses Most Procurement Teams Are Still Missing

Logan Foster — Mon, 10 Aug 2026 01:49:52 +0000

Standard SaaS vendor contracts were not written for AI. The data processing addendum you've been using since 2018 doesn't cover the scenarios that matter most when the vendor's product is an AI system making consequential decisions about your customers, employees, or operations.

Here are the clauses that most AI vendor contracts still don't include — and what to ask for in negotiations.

The Gap That Standard DPAs Don't Fill

A data processing addendum (DPA) under GDPR covers: how the processor handles personal data on behalf of the controller, sub-processor relationships, data breach notification, data subject request assistance, and return or deletion of data.

It doesn't cover:

What happens when the AI model is updated and its behavior changes
Who is responsible when an AI output causes a documented harm
What training data the AI system was built on
Whether your data is being used to train the vendor's models
What the vendor's human oversight and incident escalation procedures are
How the AI system performs across demographic groups (bias and fairness)
What security controls apply specifically to the AI components

These aren't hypothetical edge cases. They're operational risks that have materialized in real deployments — and the organizations with leverage in those situations are the ones that negotiated protections before signature, not after.

Clause 1: Model Update Notification and Stability

The problem: AI vendor contracts almost universally include broad rights to update the product. For traditional SaaS, this is fine — a UI change or a performance improvement doesn't change whether your business process works correctly. For AI systems, a model update can materially change outputs, introduce new failure modes, or break integrations that depended on consistent behavior.

What to negotiate:

Provider shall provide no less than [30/60] days' advance written notice prior to deploying any Material Model Update affecting the AI System. A "Material Model Update" includes any change to the underlying model that results in: (a) a material change in output characteristics; (b) changes to supported use cases or safety guardrails; or (c) changes to the data categories used for inference. During the notice period, Customer shall have the right to evaluate the updated model in a test environment prior to production deployment.

Minimum acceptable: Advance notice + access to changelogs that document what changed and what testing was performed.

Clause 2: Training Data Representation

The problem: AI systems trained on biased, incomplete, or harmful data produce biased, incomplete, or harmful outputs. Most AI vendor contracts say nothing about the training data underlying the model.

What to negotiate:

Provider represents and warrants that: (a) the training data used to develop the AI System was collected and processed in compliance with applicable data protection laws; (b) Provider has rights to use the training data for the purposes for which it was used; (c) reasonable steps were taken to identify and mitigate bias in the training data prior to model training; and (d) Provider will make available upon request a summary of the training data methodology, including data sources, curation processes, and bias mitigation measures undertaken.

Minimum acceptable: A model card or equivalent documentation you can review before deployment.

Clause 3: No-Training-on-Customer-Data Commitment

The problem: Many AI vendors — particularly those offering free or low-cost tiers — use customer inputs to improve their models. This creates data governance, IP, and confidentiality risks that are almost never disclosed clearly at the point of contract.

What to negotiate:

Provider shall not use Customer Data (including without limitation Customer inputs, outputs, feedback, and derived data) to train, fine-tune, or improve any AI model, algorithm, or system, including models made available to other customers, without Customer's express written consent. This restriction shall survive termination of this Agreement.

Why this matters for EU AI Act compliance: Deployers of high-risk AI systems must document data governance across the full supply chain, including what the vendor does with data. If the vendor is using your data to train models deployed to other customers, that's a data governance disclosure you likely need to make.

Clause 4: Accuracy and Performance Standards

The problem: AI vendor contracts routinely include uptime SLAs but say nothing about accuracy or performance of AI outputs. A system that's available 99.9% of the time but returns wrong answers 30% of the time meets the SLA and doesn't meet your business need.

What to negotiate:

Provider warrants that the AI System shall perform in accordance with the Performance Specifications set forth in Exhibit [X], which shall include: (a) baseline accuracy metrics by use case; (b) fairness metrics by applicable demographic categories; (c) testing methodology; and (d) performance monitoring procedures. Provider shall notify Customer within [5 business days] if performance falls below the specified thresholds, along with a remediation plan.

Minimum acceptable: A documented performance benchmark you can measure against — even if you can't negotiate a warranty, getting the baseline into the contract gives you evidence for disputes.

Clause 5: Explainability and Audit Rights

The problem: For AI systems making consequential decisions, you may need to explain those decisions to affected individuals, regulators, or internal audit. If the vendor can't or won't provide explanations for outputs, you can't fulfill your own obligations.

What to negotiate:

Provider shall make available to Customer, upon request, sufficient documentation and technical mechanisms to enable Customer to: (a) provide meaningful explanations of individual AI System outputs to affected individuals upon request; (b) conduct audits of AI System performance, including bias and fairness assessments; and (c) respond to regulatory inquiries concerning AI System operation. Provider shall cooperate with Customer's reasonable audit requests, subject to appropriate confidentiality protections.

EU AI Act relevance: For high-risk AI systems, deployers have specific obligations to enable human oversight and to provide affected individuals with information about automated decision-making. Vendor audit rights are how you fulfill those obligations when you don't own the underlying system.

Clause 6: Incident Notification for AI-Specific Events

The problem: Standard data breach notification clauses cover security incidents involving personal data. They don't cover AI-specific incidents: outputs that cause documented harm, discovery of systematic bias, safety filter failures, or adversarial attack success.

What to negotiate:

Provider shall notify Customer within [72 hours] of becoming aware of any AI System Incident, defined as: (a) AI outputs that have caused or are likely to cause material harm to individuals; (b) evidence of systematic bias or discriminatory outputs affecting protected categories; (c) safety control failures or adversarial attacks that compromised AI System integrity; or (d) third-party security researchers or regulators identifying material vulnerabilities in the AI System. Notification shall include a description of the incident, affected populations, and remediation steps.

Why this matters: EU AI Act Article 73 requires providers of high-risk AI systems to notify market surveillance authorities of serious incidents. Your vendor contract needs to ensure you receive notification fast enough to fulfill your own regulatory notification obligations.

Clause 7: Liability Allocation for AI Outputs

The problem: Standard limitation of liability clauses cap vendor liability at amounts that are often absurdly low relative to the potential harm from a wrong AI output — particularly in high-stakes contexts like credit, healthcare, employment, or legal decision support.

What to negotiate: This is the hardest clause to move on, but the negotiating position is:

Notwithstanding any limitation of liability clause, Provider's liability for: (a) AI outputs that cause harm due to Provider's failure to comply with representations and warranties; (b) data privacy breaches arising from training data misuse; or (c) failure to notify Customer of a known AI System defect, shall not be limited to less than [12 months of fees / a specified floor amount].

Minimum acceptable: A mutual understanding — documented in writing, even if not in the main agreement — of how liability would be apportioned if an AI output causes a documented harm. Getting this documented now is better than litigating the ambiguity later.

A Note on Leverage

Not every organization has the leverage to negotiate all of these clauses with every vendor. Large enterprise customers buying significant volumes have more leverage. SMBs buying standard plans typically don't.

The practical approach: prioritize Clauses 3 (no training on customer data) and 6 (AI incident notification) as non-negotiables — these protect against the risks with the highest potential consequence. Use the remaining clauses as a due diligence framework even if you can't get them in the contract — the vendor's responses tell you something about their governance maturity.

If a vendor refuses to represent that they don't train on customer data, that's information. If they can't produce any documentation of training data methodology, that's information. If they've never thought about AI-specific incident notification, that's information.

Contract negotiation is also due diligence.

Further reading:

DPIA, AIA, FRIA: The AI Governance Acronyms That Sound the Same But Aren't

Logan Foster — Sun, 02 Aug 2026 02:52:47 +0000

If you work at the intersection of privacy and AI governance, three acronyms appear constantly: DPIA, AIA, and FRIA. They're all "impact assessments." They all involve analyzing risk before deploying a system. They all produce documentation that regulators may ask to see.

They are not interchangeable. Confusing them in practice — using a DPIA where a FRIA is required, or conflating an AIA with a DPIA — is both a compliance failure and a signal that the practitioner doesn't understand what each assessment is actually for.

Here's the precise distinction.

DPIA — Data Protection Impact Assessment

Source law: GDPR Article 35
Who it applies to: Data controllers processing personal data in the EU
When it's required: When processing is likely to result in a high risk to the rights and freedoms of natural persons — specifically when: (1) using new technologies, (2) processing on a large scale, (3) systematic monitoring of publicly accessible areas, or when the processing falls into one of the categories on supervisory authority "required lists"

What it assesses:

The necessity and proportionality of the processing relative to the purpose
Risks to data subjects' rights and freedoms
Measures to address those risks, including safeguards and data protection mechanisms

Who performs it: The data controller, typically with input from the DPO (who must be consulted per Article 35(2)). External expertise may be used. Prior consultation with the supervisory authority is required when residual risk remains high after mitigation.

What it focuses on: Personal data processing risks. The DPIA lens is: what risks does this data processing create for the people whose data is being processed? It's fundamentally a data protection instrument.

Output: A documented assessment of the processing operation, its necessity and proportionality, risk analysis, and risk mitigation measures. The DPIA must be maintained and updated when the nature of processing changes.

AIA — AI Impact Assessment

Source: Not a single law — AI Impact Assessments are required under several different instruments with different scope and methodology. The EU AI Act doesn't use the term "AIA" as a formal concept; the more precise term in EU law is "conformity assessment" for high-risk systems, and "fundamental rights impact assessment" for a specific subset. "AIA" is used in US and Canadian regulatory contexts with varying definitions.

The most practically important US reference: New York City's Local Law 144 requires a "bias audit" (a form of AIA) for AI systems used in employment decisions. Several proposed US state laws use "AI Impact Assessment" with definitions that vary by jurisdiction.

General purpose of an AIA: Assess the impacts of an AI system on individuals, groups, and society — broader than data protection alone. An AIA typically addresses: accuracy and performance characteristics, fairness and potential for disparate impact, transparency and explainability, human oversight, and societal effects.

Key distinction from DPIA: A DPIA is specifically about personal data processing risks. An AIA covers a broader set of impacts, including effects on individuals who may not even be data subjects of the system being assessed. A DPIA can be a component of an AIA, but an AIA is not a DPIA.

Practical use: In organizations that have formalized their AI governance process, the AIA is often the primary governance instrument for AI system review — the assessment that determines risk tier, required controls, and deployment conditions for any AI system, regardless of whether a DPIA is separately required.

FRIA — Fundamental Rights Impact Assessment

Source law: EU AI Act Article 27
Who it applies to: Deployers (not Providers) of high-risk AI systems listed in Annex III of the EU AI Act — with a specific exemption for small and micro-enterprises in some contexts
When it's required: Before deploying a high-risk AI system in the categories covered by Annex III (employment, education, access to essential services, law enforcement, migration, justice, critical infrastructure, biometrics)

What it assesses:

The purpose and context of deployment
The categories of persons at risk of being affected
The specific fundamental rights at risk: privacy, non-discrimination, dignity, fair trial, freedom of expression, and others
The magnitude and probability of impacts on those rights
Mitigation measures planned to address identified risks
Human oversight mechanisms
Specific risks for vulnerable groups (children, people with disabilities, minorities)

Who performs it: The Deployer — the organization that puts the AI system into use — not the Provider (vendor) that built the system. The FRIA is separate from the Provider's conformity assessment obligations.

What it focuses on: Fundamental rights — specifically, the rights in the EU Charter of Fundamental Rights that an AI system in use could affect. The FRIA lens is broader than data protection: it includes due process rights, freedom of expression, rights to equality and non-discrimination, and the right to effective remedy.

Output: A documented assessment specific to the deployer's context and use case. Two organizations using the same high-risk AI system from the same vendor will produce different FRIAs if their deployment contexts differ — different affected populations, different decision-making contexts, different human oversight arrangements.

The Article 27(4) bridge: Where a DPIA is also required for the same processing, the EU AI Act explicitly allows the FRIA and DPIA to be conducted jointly, using Article 35 GDPR as the procedural framework. This is the most efficient path for organizations facing both obligations simultaneously.

Side-by-Side Comparison

	DPIA	AIA (general)	FRIA
Legal basis	GDPR Art. 35	Various (NYC LL144, state laws, internal policy)	EU AI Act Art. 27
Triggered by	High-risk personal data processing	AI system deployment (varies by framework)	High-risk AI system deployment (Annex III)
Performed by	Data controller	Varies	Deployer
Core focus	Personal data risks	AI system impacts broadly	Fundamental rights impacts
Scope of affected parties	Data subjects	Anyone affected	Anyone affected, with emphasis on vulnerable groups
Regulator involved	Supervisory authority (GDPR)	Varies	Market surveillance authority (AI Act)
Required update	When processing changes significantly	Varies	When AI system or deployment context changes significantly

When You Need Which (And When You Need More Than One)

Deploying an AI-powered HR screening tool in the EU:

DPIA: Yes — systematic processing of employee/candidate personal data using new technology, high-risk per GDPR
FRIA: Yes — employment AI is explicitly listed in Annex III; deployer must complete before deployment
AIA (internal): Strongly recommended as the overarching governance document, with DPIA and FRIA as component sections

Deploying an AI fraud detection system for a financial services firm:

DPIA: Yes — large-scale processing of transaction data
FRIA: Potentially — depends on whether the system meets the Annex III criteria for "access to essential services" (credit, insurance)
AIA: Yes as internal governance

Deploying an AI content recommendation system with no GDPR obligations (non-EU, no personal data):

DPIA: No GDPR obligation
FRIA: No EU AI Act obligation (assuming non-EU deployment)
AIA: Depends on internal governance policy and any applicable local law

The Exam Angle

For AIGP candidates, this is one of the highest-yield topic areas — because it's exactly the kind of practical distinction that scenario-based questions test. A question that describes a high-risk AI deployment in an EU financial institution and asks what assessments are required has a specific, defensible answer that requires knowing all three frameworks and how they interact.

The answer isn't "conduct an impact assessment." It's: DPIA under GDPR Article 35, FRIA under EU AI Act Article 27, potentially using the Article 27(4) combined procedure, with the DPIA process providing the procedural framework.

Further reading:

AI Chatbot Legal Liability: What the First Real Cases Actually Show

Logan Foster — Sat, 25 Jul 2026 02:20:14 +0000

For years, AI liability was a theoretical discussion. Legal scholars debated frameworks. Regulators drafted guidance. Governance professionals built policies around risks that hadn't yet materialized in court.

That phase is over.

The first wave of AI chatbot liability cases has now produced real rulings, real damages, and real precedents. If you're in legal, compliance, or AI governance, here's what the actual cases show — and what they mean for organizations deploying AI-facing customer interactions.

The Air Canada Case: Vicarious Liability for Chatbot Outputs

The most cited early case is Air Canada's. A passenger used Air Canada's website chatbot to ask about bereavement fares — reduced fares available when traveling due to a family death. The chatbot told the passenger he could purchase a full-fare ticket and apply for a bereavement discount retroactively within 90 days.

That was wrong. Air Canada's actual policy didn't allow retroactive applications. The passenger bought the ticket based on the chatbot's representation, applied for the discount, and was denied. Air Canada's defense was that the chatbot was "a separate legal entity" and the airline couldn't be responsible for its outputs.

The Canadian Civil Resolution Tribunal rejected that argument entirely. The ruling held that Air Canada was responsible for the information on its website — including information provided by its chatbot. The passenger was awarded the fare difference plus additional costs.

The governance implication: Your chatbot is you. Whatever outputs your AI-facing tools produce are legally attributable to your organization, on the same basis as any other organizational communication. "The AI said it, not us" is not a defense.

What the Cases Have in Common

Looking across the cases that have now been adjudicated or settled, a few patterns emerge:

Reliance is the key element. In cases where plaintiffs have succeeded, the common thread is that they relied on the AI output to take a specific action — and the output was wrong. The question courts ask is whether reliance was reasonable given the context. A chatbot on an official company website answering questions about that company's own policies creates reasonable reliance. A third-party AI tool that explicitly disclaims accuracy creates less.

Disclaimers help but don't fully protect. Several cases have tested whether "AI-generated content may be inaccurate" disclaimers insulate organizations from liability. The general finding is that generic disclaimers reduce but don't eliminate exposure — particularly when the deployment context implies reliability (official customer service channel, professional advice context, regulated industry).

The professional services context is highest-risk. Cases involving AI outputs that resemble professional advice — legal, medical, financial — face the most scrutiny. An AI tool that helps users understand their legal rights, describes medication interactions, or provides specific financial recommendations is in territory where the standard of accuracy is high and the harm from inaccuracy is concrete.

Third-party AI providers don't absorb organizational liability. Several organizations have attempted to deflect liability to the AI model provider. Courts have generally focused on the deployer — the organization that put the AI in front of users — as the accountable party. The AI provider's terms of service may create indemnification rights between the two parties, but from a user's perspective, the deployer is the defendant.

The Regulatory Layer on Top

Legal liability from cases is one exposure. Regulatory enforcement is a parallel track that's moving faster.

The EU AI Act creates specific obligations for AI systems that interact with users directly. Chatbots must disclose they are AI systems when interacting with humans (Article 50), unless it's obvious from context. "Obvious from context" is a narrower category than most organizations assume — a customer service chat interface that looks and responds like a human agent may not qualify.

Emotion recognition in customer service contexts is now prohibited in the EU. AI systems that infer customer emotional state to influence how interactions are handled fall into prohibited territory.

The FTC has issued guidance on AI in customer-facing contexts, focusing on deceptive practices — situations where AI outputs mislead consumers in ways that affect their decisions. The CFPB has specifically addressed AI in credit-related customer interactions.

The practical implication is that legal liability from cases and regulatory enforcement risk aren't separate problems to manage sequentially. They're concurrent exposures that require concurrent governance responses.

What Defensible Chatbot Governance Looks Like

Based on the cases and the regulatory direction, the organizations with the lowest liability exposure share these characteristics:

Clear, contextual disclosure. Not buried in terms of service — present in the interaction itself. "You're chatting with an AI assistant" at the start of the conversation, not as a footnote.

Defined scope with hard limits. The chatbot can answer questions about X, Y, Z. For anything outside that scope, it routes to a human. Not "it tries to answer and might get it wrong" — it explicitly refuses and escalates. This is a design decision, not just a policy decision.

Human escalation for consequential decisions. Any interaction that could result in a significant customer decision — a purchase, a contract, a claim, an application — should have a defined human review or confirmation step. The chatbot can support the decision; it shouldn't be the sole determinant.

Output auditing. Organizations that can demonstrate they monitored chatbot outputs, identified error patterns, and made corrections are in a materially better position than organizations that deployed and didn't monitor. This isn't just good governance — it's evidence that the organization took reasonable precautions.

Third-party AI vendor contracts with explicit representations. Your AI vendor contract should include representations about output accuracy standards, notification requirements for model updates that could change behavior, and indemnification provisions. If your current contract doesn't include these, that's a gap worth addressing before the next renewal.

The Bottom Line for AI Governance Leaders

The era of theoretical AI liability is over. The cases are real. The precedents are forming. And the organizations that built governance frameworks before the cases arrived are in a better position than the ones that are building them in response.

If your organization deploys any AI system that interacts with customers, employees, or third parties — chatbots, recommendation systems, automated decision tools — the governance question isn't "could we be liable?" It's "can we demonstrate we took reasonable precautions?"

Document the controls. Log the outputs. Define the scope. Build in the human escalation. Those are the elements that distinguish organizations with defensible governance from organizations that become case studies.

Further reading:

How to Build an AI Governance Program From Scratch

Logan Foster — Sat, 18 Jul 2026 10:43:17 +0000

Most AI governance programs don't fail because nobody understood the regulations.

They fail because the program was built as a document — a policy PDF, a slide deck, a framework mapping exercise — instead of an operating model with owners, cadence, and consequences.

If you've been handed the job of standing up AI governance from nothing, here's the sequence that produces something that still runs six months after the kickoff meeting.

Step 1: Inventory Before You Govern

You cannot govern what you haven't found.

Before selecting a framework, drafting a policy, or buying a governance tool, your first deliverable should be a complete AI system inventory. Not an aspirational list of "AI capabilities we might use" — an actual registry of AI systems currently in production or in active development.

For each system, capture:

What the system does and what decision or output it produces
Who owns it (a named individual, not a team)
What data it uses and where that data comes from
Who the affected parties are (employees? customers? the public?)
Whether it was built in-house, purchased from a vendor, or uses a third-party model API

This exercise usually surfaces more systems than anyone expected. Organizations routinely discover AI deployed in HR tools, customer service platforms, fraud detection layers, and marketing automation that nobody in legal or compliance knew was there.

The inventory is not a one-time exercise. It needs a process: an intake gate that requires AI system registration before any new AI project gets approved, budget, or infrastructure access.

Step 2: Classify Before You Control

Once you have the inventory, classify each system by risk — but use a classification methodology that produces legally defensible categories, not just a color-coded spreadsheet.

If you operate in the EU or work with EU residents, the EU AI Act's risk tier structure is your starting framework. The Act distinguishes between:

Prohibited practices — you need a documented representation that none of your systems fall here
High-risk systems — Annex III lists eight specific use-case areas (employment, credit, education, healthcare, biometrics, law enforcement, migration, justice)
Limited risk — specific transparency obligations apply (chatbot disclosure, deepfake labeling)
Minimal risk — no mandatory requirements, but internal governance still applies

If you operate outside the EU or exclusively domestically, use the NIST AI Risk Management Framework's risk profiles or ISO/IEC 42001's risk criteria as your classification baseline.

The output of classification is a tiered inventory: which systems need full conformity assessments, which need transparency measures, and which need only light-touch internal governance.

Document the rationale for every classification. "We decided this wasn't high-risk" is not a defensible position if a regulator asks. "We assessed this system against Annex III criteria and concluded it doesn't fall within the scope of employment AI because it doesn't filter candidates or make promotion decisions — here's the evidence" is.

Step 3: Assign Owners, Not Teams

The most common structural failure in AI governance programs is assigning ownership to teams or committees rather than named individuals.

Every AI system in your registry needs a named System Owner who is accountable for:

Keeping the system's governance documentation current
Triggering reassessment when the system changes materially
Ensuring human oversight mechanisms are operational
Escalating incidents or anomalies

The System Owner doesn't have to be a governance expert. They should be whoever is operationally closest to the system — typically the product manager or engineering lead responsible for it. Governance expertise lives in the AI governance function; accountability for a specific system lives with the person who knows it best.

This design avoids the commons problem: when "the AI committee" is responsible for everything, nobody is responsible for anything specific.

Step 4: Build Policies That Point to Processes

AI governance policies are not the end goal. They're signposts that point to processes.

A policy that says "the company will conduct AI impact assessments for high-risk systems" is meaningless without a defined impact assessment process, a template, a review cadence, and a named function responsible for conducting them.

For each policy statement, you should be able to answer:

Who does this?
How? (what's the process?)
When? (what triggers this activity?)
Where does the output live?
Who reviews it?

If you can't answer all five, the policy isn't operational yet.

The minimum viable policy set for most organizations in 2026:

AI Use Policy (what AI is permitted, what isn't, what requires approval)
AI Risk Assessment Procedure (how you classify and document system risk)
AI Incident Response Procedure (what happens when something goes wrong)
Third-Party AI Vendor Policy (what contractual and due diligence requirements apply)
Human Oversight Standards (which systems require human review before acting on AI output)

Step 5: Attach Governance to Existing Processes

The biggest implementation mistake is building AI governance as a parallel track that runs separately from how your organization actually makes decisions.

If your organization has a Change Advisory Board for technology changes — the AI governance review should happen before CAB, not after. If you have a vendor procurement process — AI vendor assessments should be part of that workflow, not a separate AI team process that runs concurrently.

Governance that requires people to do extra steps outside their normal workflow gets bypassed. Governance that lives inside the workflow gets followed.

Identify where in your existing processes the AI governance checkpoints should live:

Procurement: AI vendor assessment before contract signature
Development: Risk classification before project approval
Deployment: Conformity check before production launch
Ongoing: Periodic system review on a cadence tied to risk tier

Step 6: Measure Something

A governance program with no metrics is a compliance theater exercise.

At minimum, track:

Coverage rate: What percentage of AI systems in the inventory have completed risk classification?
Assessment completion: Of systems requiring a formal impact assessment, what percentage have one that's current?
Incident rate: How many AI-related incidents (errors, bias complaints, unexpected outputs) were reported in the last quarter?
Third-party compliance: What percentage of AI vendor contracts include required governance representations?

These don't need to be perfect. They need to tell you whether the program is actually running or just documented as running.

What to Avoid

Don't start with framework selection. Choosing between NIST AI RMF, ISO 42001, and EU AI Act compliance before you know what systems you have is backwards. The framework should match your inventory and your regulatory context, not precede it.

Don't build a committee as a governance substitute. An "AI Ethics Committee" that meets quarterly and reviews submissions is not a governance program. It's a review board. Governance is the operating infrastructure that ensures the right things happen before anything reaches a review board.

Don't treat the policy launch as the finish line. The launch is month one. The measure of the program is whether it's still running operationally at month six, month twelve, and beyond.

The Honest Timeline

For most mid-sized organizations (1,000–10,000 employees, 10–50 AI systems in active use), expect:

Month 1–2: AI inventory and initial classification
Month 2–3: Policy drafting, owner assignment, process design
Month 3–4: Integration into existing workflows
Month 4–6: First cycle of formal assessments for high-risk systems
Month 6+: Ongoing operation, metrics tracking, iteration

Building it faster is possible. Building it to last requires the time to get the owner assignment and workflow integration right.

Further reading: