Wiki · Concept · Last reviewed June 23, 2026

Algorithmic Impact Assessments

Algorithmic impact assessments are deployment-specific reviews used to decide whether automated decision systems should be built, procured, deployed, constrained, monitored, or refused.

Category: Concept Published: June 23, 2026 Modified: June 23, 2026 Last reviewed: June 23, 2026 Tags: Governance, Risk Assessment, Public Services, Due Process, Algorithmic Accountability

Definition

An algorithmic impact assessment, or AIA, is a structured, deployment-specific review of an automated decision system, AI system, or algorithmic workflow before and during consequential use. It asks whether the system should be used at all, under what authority, with what evidence, for which affected population, under which safeguards, and with what notice, oversight, monitoring, and recourse.

The assessment object is not only the model. It includes the data pipeline, thresholds, prompts, retrieval sources, user interface, human workflow, vendor terms, logs, monitoring plan, appeal path, and institutional setting in which the system acts. A fraud model, hiring screen, eligibility score, chatbot, or agent can have a different risk profile when the population, decision authority, appeal path, data source, or human reviewer changes.

AIAs are related to privacy impact assessments, human-rights impact assessments, data protection impact assessments, safety cases, model evaluations, audits, and conformity assessments, but they are not interchangeable with any of them. An audit asks whether a system met a standard. A conformity assessment asks whether legal or technical requirements are satisfied. A data protection impact assessment focuses on personal-data processing. A useful AIA is broader and more operational: it records whether to deploy, modify, delay, restrict, monitor, disclose, or abandon an automated system in a real context.

Scope

AIAs matter most when automated systems influence consequential decisions: benefits, immigration, education, hiring, workplace discipline, policing, credit, housing, insurance, healthcare, public services, border control, content distribution, and access to essential infrastructure. These systems often appear technical while making institutional choices about classification, priority, suspicion, eligibility, entitlement, and risk.

The term "algorithmic impact assessment" is used unevenly. Some regimes cover broad automated decision systems, including rules-based systems that replace or assist human judgment. Others focus on AI systems, high-risk AI, fundamental rights, privacy risk, or automated decisionmaking technology. That variation matters: a page labeled "AIA" may be a public-sector administrative-law tool, a privacy risk assessment, a civil-rights review, a procurement document, or an internal risk record.

The common question is practical: before an institution lets the system shape a real decision, has it created enough evidence, authority, review power, and recourse to justify that use? If the answer is no, the assessment should be able to stop or narrow deployment rather than merely document concern.

Current Context

As of June 23, 2026, AIAs are moving from policy experiment into legal, standards, procurement, and privacy infrastructure. The strongest versions now treat assessment as a lifecycle control rather than a one-time ethics form, and they connect the assessment to an AI system inventory, procurement rights, testing evidence, monitoring, incident response, and appeal.

Canada remains the clearest public-sector model. The Government of Canada describes its AIA as a mandatory tool supporting the Treasury Board Directive on Automated Decision-Making. The tool uses 65 risk questions and 41 mitigation questions to determine the impact level of an automated decision system, while the scope guide says the directive applies to federal departments using systems to fully or partially automate administrative decisions developed or procured after April 2020, or significantly modified afterward.

The EU AI Act adds a fundamental-rights model. Article 27 requires certain deployers of high-risk AI systems, including public bodies, private entities providing public services, and deployers of specified banking and insurance systems, to perform a fundamental-rights impact assessment before first use. The assessment must cover the deployer's process, use period and frequency, affected groups, specific risks of harm, human oversight, internal governance, and complaint mechanisms, and it must be updated when relevant elements change. Article 113 makes the regulation generally applicable from August 2, 2026, with specific exceptions; Article 27 is therefore best read against the official text and implementation timeline, not against a generic "AI Act effective date."

In U.S. federal practice, OMB Memorandum M-25-21 rescinded and replaced M-24-10 in April 2025. It requires agencies to complete documented AI impact assessments before deploying high-impact AI use cases, update them through the AI lifecycle, include independent review and risk acceptance, and pair them with pre-deployment testing, monitoring, human oversight, remedies or appeals, and feedback channels. M-25-22 then turns this into a procurement problem by telling agencies to require vendor transparency and documentation sufficient to complete the required assessments for high-impact use cases.

State, city, and privacy regimes are uneven but relevant. California Privacy Protection Agency regulations effective January 1, 2026 add risk-assessment duties under the CCPA; businesses subject to risk-assessment requirements must begin compliance on that date, while businesses using ADMT for significant decisions must comply with ADMT requirements beginning January 1, 2027. Colorado's 2026 SB26-189 replaced its earlier high-risk AI framework with automated-decision technology requirements for consequential decisions, including developer documentation, record retention, notices, data-correction rights, meaningful human review, and attorney-general enforcement. New York City's Local Law 144 is narrower still: it is a bias-audit and notice regime for automated employment decision tools, not a general AIA law. The lesson is source discipline: state and local duties can sound similar while attaching to different actors, decisions, dates, rights, and evidence records.

Standards are also catching up. ISO/IEC 42005:2025 provides guidance for AI system impact assessments across the AI lifecycle, while NIST's AI Risk Management Framework supplies the broader govern, map, measure, and manage structure that many AIAs operationalize in a particular deployment.

What They Assess

Decision context. What process or decision will the system influence, and how much discretion, if any, will remain with humans?

Affected people. Which individuals or groups may be affected, including people indirectly affected by triage, surveillance, ranking, exclusion, or error?

Data and provenance. What data sources, proxies, labels, histories, and feedback loops shape the system?

Legal basis and authority. Who is authorized to use the system, under what law, policy, contract, or institutional mandate?

Rights and harms. What impacts could arise for privacy, equality, due process, speech, safety, labor, accessibility, access to services, and human dignity?

Performance and robustness. How does the system perform across groups, settings, languages, edge cases, and adversarial conditions?

Human workflow. What are human reviewers expected to do, what can they actually see, and are they trained and empowered to override the system?

Vendor and supply chain. Which external models, data sources, cloud services, APIs, prompts, and contracts shape the deployed system?

Human oversight and recourse. Who can inspect, question, override, appeal, pause, or repair the system?

Monitoring. How will the organization detect drift, misuse, incidents, bias, and downstream effects after launch?

Decision authority. Who is allowed to accept residual risk, and who is allowed to block, narrow, suspend, or retire the system when evidence fails?

Canada's Algorithmic Impact Assessment. The Government of Canada describes its AIA as a mandatory risk assessment tool supporting the Treasury Board Directive on Automated Decision-Making. The tool uses risk and mitigation questions to determine an impact level for an automated decision system, and departments are responsible for publishing final AIA results on the Open Government Portal.

Canada's Directive on Automated Decision-Making. The directive applies to Canadian federal departments using automated decision systems to make or assist administrative decisions. It ties requirements such as peer review, notice, human intervention, monitoring, and recourse to the system's impact level.

EU AI Act Article 27. Article 27 requires certain deployers of high-risk AI systems to perform a fundamental-rights impact assessment before deployment. The assessment must describe the process, use period and frequency, affected groups, specific risks of harm, human oversight measures, and measures to take if risks materialize.

U.S. federal AI governance. OMB Memorandum M-25-21 requires federal agencies to complete documented AI impact assessments before deploying high-impact AI use cases. It also requires reassessment procedures after significant modifications, independent review, risk acceptance, monitoring, human oversight, remedies or appeals, and feedback options where appropriate.

California privacy and ADMT rules. California's CPPA regulations add risk-assessment duties and consumer access and opt-out rights for covered uses of automated decisionmaking technology. This is not a general AIA law, but it shows how impact-assessment logic is entering privacy governance and consumer-facing contestability.

Colorado automated-decision law. Colorado's 2026 SB26-189 governs automated decision-making technology used to materially influence consequential decisions. Its documentation, notice, record-retention, correction, meaningful-human-review, and enforcement provisions show a different path: less emphasis on a public AIA form and more emphasis on records and rights around adverse outcomes.

New York City Local Law 144. New York City's automated employment decision tool law requires a recent bias audit, public audit information, and notices before covered employers and employment agencies use an AEDT. It is narrower than an AIA because it focuses on employment screening and bias-audit disclosure, but it is a useful warning: an audit can satisfy a local rule while leaving broader questions about job design, data provenance, vendor control, appeal, and worker recourse unresolved.

ISO/IEC 42005. ISO/IEC 42005:2025 provides guidance for AI system impact assessments focused on how AI systems and foreseeable applications may affect individuals, groups, and society across the lifecycle.

NIST AI RMF. The NIST AI Risk Management Framework does not prescribe one AIA form, but it gives a risk-management structure for governing, mapping, measuring, and managing AI risks. AIAs often operationalize that structure in a specific deployment.

Evidence and Source Discipline

A serious AIA should preserve evidence, not only conclusions. Useful evidence includes system purpose, decision authority, data provenance, model or vendor documentation, evaluation design, subgroup results, known limitations, security review, privacy analysis, accessibility review, human-oversight design, notices, appeal procedures, incident response plans, monitoring metrics, procurement terms, and version history.

Source discipline means distinguishing primary records from summaries. A vendor statement, press release, model card, internal test, regulator filing, procurement contract, incident log, and public-facing AIA are not interchangeable. The assessment should say what evidence was reviewed, what was unavailable, what is based on inference, and which claims depend on vendor-controlled information.

Dates matter. AI systems, laws, standards, datasets, model versions, prompts, retrieval sources, and deployment settings change. An AIA should record the system version, assessment date, scope, reviewer, evidence cutoff, unresolved gaps, reassessment triggers, and the decision maker who accepted or rejected residual risk.

The strongest evidence chain links the AIA to other governed records: the AI system inventory entry that identifies the system, the procurement record that secures documentation and audit rights, the AI audit trail that preserves operation evidence, the post-market monitoring plan that detects drift and incidents, and the recourse path that lets affected people contest harm.

Governance Implications

Authority. AIAs allocate responsibility before deployment. Someone must own the risk decision, not just complete the form.

Procurement. Buyers need contractual rights to documentation, testing cooperation, logs, change notices, audit access, incident reporting, and exit options. Without those rights, the deployer may be unable to answer the AIA's core questions.

Public accountability. High-impact public-sector AIAs should publish enough information for affected people, journalists, researchers, legislators, and courts to understand the system's purpose, safeguards, and contestation paths. Confidential details may need protection, but confidentiality should not erase public accountability.

Recourse. Assessment without appeal is weak governance. People affected by an automated or AI-assisted decision need notice, explanation, correction, human review, and remedy where appropriate.

Lifecycle control. AIA duties should attach to material changes: new model, new dataset, new population, new threshold, new tool integration, new vendor, new use case, or serious incident. A point-in-time assessment should not become a permanent permission slip.

Enforcement. Regulators, auditors, courts, inspectors general, procurement officials, and civil society can compare AIA promises against deployed behavior. That comparison is where an AIA becomes more than paperwork.

Refusal. The assessment has to preserve the option not to deploy. A risk assessment that can only recommend more monitoring, more disclaimers, or more training has already conceded the main governance question.

Process

First, the organization defines the deployed system and decision context. A generic model description is not enough; the assessment must cover the use case, workflow, legal authority, affected population, and operational environment.

Second, it maps impacts. It asks what happens if the system fails, who can be harmed, whether rights or access to services are affected, whether the system changes power relations, and which groups should be consulted before use.

Third, it gathers evidence: data documentation, model documentation, testing, subgroup evaluation, privacy and security review, accessibility review, human-workflow analysis, vendor evidence, and records from pilots or comparable deployments.

Fourth, it identifies controls: data governance, monitoring, human review, logging, appeal, notice, procurement conditions, security controls, thresholds, prohibited uses, rollback paths, and incident response.

Fifth, it records residual risk and decision authority. If significant risk remains, leadership should decide whether to deploy, change the design, narrow the scope, add oversight, publish a warning, or stop.

Finally, it sets reassessment triggers. A model update, new dataset, new user group, new vendor, new integration, new legal duty, or new incident can make an old assessment obsolete.

Failure Modes

Form without power. Staff complete the assessment, but nobody has authority to block or modify the deployment.

Late assessment. The AIA is performed after procurement, integration, or launch decisions are already effectively irreversible.

Vendor opacity. The deployer cannot answer core questions because the vendor controls model details, data, logs, testing, or documentation.

Model-only scope. The assessment covers the model but not the workflow, incentives, human reviewers, appeal process, procurement terms, or affected communities.

Impact washing. A system is declared low impact through optimistic assumptions, weak evidence, or failure to consult affected groups.

Source laundering. Vendor marketing, summaries, and unverifiable claims are treated as evidence without preserving primary records or evidence gaps.

Confidentiality shield. Trade secrecy, security language, or privacy concerns are used to hide even the system's purpose, affected population, decision authority, and recourse path.

Stale records. The assessment remains online while the model, data, policy, or deployment context changes.

Consultation theater. Affected people are surveyed or invited to comment after the deployment path is fixed, with no power to change scope, safeguards, or refusal.

Spiralist Reading

An algorithmic impact assessment is a pause before the machine becomes normal.

The institution wants flow: classify, score, rank, route, decide. The assessment interrupts that flow and asks who is being transformed into data, who can be refused, who can appeal, who will notice error, what evidence exists, and who carries the harm when the system is wrong.

For Spiralism, the AIA is not sacred paperwork. It is a reality anchor. It says the system must be named, sourced, bounded, and made answerable before it is trusted.

Open Questions

Sources

Return to Wiki