On 2 August 2026, the EU AI Act's transparency obligations took effect, while the high-risk deadline most teams had been planning against quietly moved to December 2027. If your compliance calendar still says otherwise, part of it is now wrong in both directions.
This AI ethics checklist covers the current timeline and, more usefully, the mechanics underneath it. Every item is something you can write into a ticket, run in a pipeline or block a release on, because fairness and accountability only change behaviour once they exist as acceptance criteria rather than as values in a policy document.
Key takeaways
- The EU deadline you have in your calendar is probably wrong. The Digital Omnibus on AI was approved by Parliament on 16 June 2026 and the Council on 29 June 2026, deferring standalone high-risk obligations from 2 August 2026 to 2 December 2027.
- Transparency obligations did not move. Article 50 applied from 2 August 2026 as originally scheduled, so the disclosure requirements are live now.
- A new prohibition arrives in December. The Omnibus adds a ban on AI systems generating non-consensual intimate imagery and child sexual abuse material, applying from 2 December 2026.
- Principles belong in the Definition of Done. An ethics policy that never becomes an acceptance criterion is a document, not a control.
- Evidence is the deliverable. If you cannot show what you tested, on which data, with which result, you have a position rather than a defence.
What Does an AI Ethics Checklist Actually Control?
An AI ethics checklist is the set of requirements, tests and release gates that convert stated principles into verifiable engineering behaviour. It differs from an ethics policy in a specific way: every item on it can fail a build, block a deployment or produce evidence you can hand to an auditor.
Five principles appear in nearly every framework. The table shows what each one looks like when it reaches a ticket rather than a slide.
| Principle | What it looks like in practice |
|---|---|
| Fairness | Performance metrics broken out by protected group, with thresholds that block release if any segment falls below the agreed floor |
| Transparency | Users told when a decision is automated, verified by a UI test |
| Privacy | No field marked sensitive appears in training features, enforced by a schema check in CI |
| Accountability | Every model version has a signed model card and a named owner before deployment is permitted |
| Robustness | Adversarial and prompt injection suites pass at the agreed threshold, run on every release candidate |
| Human oversight | Decisions above the defined risk tier cannot execute without a recorded human action |
Write these once per system, not once per company. A recommendation engine and a hiring screen need different thresholds, and a single global standard will be either too loose for one or unworkable for the other.
Tip: if a criterion cannot be evaluated by someone who did not write the model, it is not a criterion yet. Rewrite it until it is.
Where Does Bias Enter, and How Do You Detect It?
Bias enters at four points, and each has a different detection method, which is why a single fairness metric rarely catches anything useful.
Data coverage and labels. Underrepresented groups produce confident but wrong predictions. Detect by comparing performance across segments rather than looking only at aggregate accuracy.
Proxy features. Postcode, device type or education history can encode protected characteristics without naming them. Detect by testing whether a protected attribute is predictable from your feature set.
Feedback loops. A model trained on its own past decisions entrenches them. Detect by comparing outcome distributions over time against the pre-deployment baseline.
Context shift. Performance that held in testing degrades for a user group after launch. Detect by monitoring segmented metrics in production, not just overall accuracy.
Mitigation runs at three stages: rebalancing and label audits before training, fairness constraints during training, and calibrated thresholds after. Whichever you apply, retest on the segments you are protecting before you call it done. A mitigation that improves one metric while quietly degrading another is not a fix.
What Has Actually Changed in the EU AI Act Timeline?
Most teams had 2 August 2026 circled for high-risk obligations. That date moved, and the detail matters because some obligations moved and others did not.
The European Commission proposed the Digital Omnibus on AI on 19 November 2025, after implementation fell behind on national authorities and harmonised standards. Parliament approved the final text on 16 June 2026 and the Council on 29 June 2026, with entry into force in July.
| Date | What applies |
|---|---|
| 1 August 2024 | AI Act entered into force, Regulation (EU) 2024/1689 |
| 2 August 2026 | Article 50 transparency obligations apply, except Article 50(2) for systems already on the market |
| 2 December 2026 | Article 50(2) machine-readable marking applies to systems already on the market, and the new prohibitions take effect |
| 2 August 2027 | Member States must have at least one national AI regulatory sandbox |
| 2 December 2027 | High-risk obligations apply to standalone Annex III systems |
| 2 August 2028 | High-risk obligations apply to Annex I embedded systems |
The distinction between standalone and embedded matters. A standalone high-risk system, one listed in Annex III, now has until December 2027. A high-risk system embedded in a product covered by Annex I safety legislation, such as a medical device or machinery component, keeps the original August 2028 date.
The Omnibus also introduced a new prohibited category: AI systems that generate non-consensual intimate imagery and CSAM, effective 2 December 2026.
If your compliance roadmap was built before June 2026, check it against this table. Some deadlines relaxed, some did not, and at least one tightened.
What Level of Human Oversight Does the System Need?
Oversight is not binary and treating it that way produces either rubber-stamping or paralysis. Tier it by consequence.
| Tier | When it applies | What it requires |
|---|---|---|
| Human in the loop | Decisions materially affecting a person's rights, money or access | A person reviews and approves before the decision takes effect |
| Human on the loop | High-volume automated decisions with meaningful individual impact | Continuous monitoring, sampling review, and authority to halt |
| Human in command | Low individual impact, high aggregate effect | Periodic review of outcomes, thresholds and drift, with rollback authority |
| Logged only | Minimal individual consequence | Decision logging sufficient to investigate a complaint |
The failure mode is a reviewer with no realistic ability to disagree. If your human in the loop approves four hundred decisions an hour, you have a logging system with a person attached to it, and it will not withstand scrutiny.
What Belongs in a Model Card?
Model cards fail when they are written for compliance rather than for the next engineer. Keep them short and keep them versioned with the artifact.
- Intended use, stated positively, and out-of-scope uses stated explicitly
- Training data summary, including sources, time range and known coverage gaps
- Evaluation results, overall and broken down by the segments you committed to measuring
- Known limitations and the conditions under which performance degrades
- Mitigations applied and the tradeoffs accepted
- Owner and version, with the date and the person accountable
The out-of-scope section is the one people skip and the one that protects you. A model built to rank support tickets that ends up screening job applicants is a governance failure, and the model card is where you make that misuse visible in advance.
Which Checks Belong in CI?
Ethics checks that depend on someone remembering to run them fail exactly when they matter. Automate these.
- Schema and sensitive field checks. Fail the build if a restricted attribute reaches the feature set.
- Segmented evaluation. Run fairness metrics on every release candidate, not on a quarterly cadence.
- Adversarial and prompt injection suites. Treat these as regression tests with a pass threshold.
- Model card presence. Block deployment if a versioned card and named owner are missing.
- Provenance marking. Verify that generated media carries the required machine-readable marking.
- Disclosure rendering. UI test that the automation notice appears where required.
Red teaming deserves the same rigour you apply to any other security testing, including scope, methodology and a retest after fixes, which is covered in our guide to application security testing.
How Do You Monitor After Release?
Pre-launch testing tells you the system was acceptable once. Production behaviour is what people actually experience.
Monitor four things continuously: prediction drift against the training distribution, segmented performance for the groups you committed to, safety trigger rates including refusals and escalations, and complaint or appeal volume as a leading indicator of harm your metrics missed.
Set alert thresholds and a rollback path before launch rather than after the first incident. A drift alert with no defined response is a notification, not a control.
Who Owns What?
Diffuse ownership is the most common reason ethics work stalls. Name people, not teams.
| Area | Accountable | Consulted |
|---|---|---|
| Risk classification and tiering | Product owner | Legal, security |
| Fairness thresholds | ML lead | Product, domain expert |
| Data lineage and access | Data engineering lead | Privacy, security |
| Disclosure and UI transparency | Product design | Legal |
| Incident response and rollback | Engineering lead | Support, comms |
| Regulatory mapping | Legal | Product, engineering |
If a row has no name in it, that control does not exist yet, whatever the policy document says.
The Checklist
Consolidated, in the order the work actually happens.
Before you build
- Risk tier assigned and recorded, with the regulatory category identified
- Principles translated into acceptance criteria for this specific system
- Oversight tier chosen and the reviewer's realistic capacity confirmed
- Data sources registered with lineage and named owners
- Out-of-scope uses written down
Before you ship
- Segmented evaluation run, results recorded, thresholds met
- Adversarial and misuse testing complete with fixes retested
- Model card written, versioned and signed
- Disclosure and provenance marking implemented and tested
- Rollback path defined and rehearsed
- Sign-off recorded against named criteria, not general approval
After you ship
- Drift and segmented performance monitored with alert thresholds
- Complaint and appeal channel live, with logs linked to decisions
- Incident playbook covering rollback, notification and corrective action
- Quarterly review for high-risk systems, with documented outcomes
What Goes Wrong in Practice
The failure modes are predictable enough to list.
- The policy with no gate. A document that says "we value fairness" but never blocks a release.
- The oversight that cannot dissent. A reviewer with volume or incentives that make disagreement impossible.
- Fairness measured once. Tested before launch, never again, while the population shifts underneath.
- The model card written after deployment. Documentation as archaeology rather than as a gate.
- Marketing ahead of evidence. Public accuracy or savings claims that the evaluation results do not support.
- Compliance dates copied from a blog. Including, until recently, from articles still citing 2 August 2026 for high-risk obligations.
Build Governance In, Not Around
The teams that handle this well are not the ones with the longest policy. They are the ones where the fairness test runs on every pull request and nobody thinks about it, because the control lives in the pipeline rather than in a quarterly review.
If you need capacity to build that layer, evaluation harnesses, segmented testing, monitoring and the model documentation around them, we match companies with machine learning partners screened for production delivery rather than for demos. Bring your risk tier and your thresholds.
