The previous chapters examined the systems that shape immigration outcomes before a judge ever sees the case: data-fusion platforms, detention classifiers, supervision scores, text-analytics tools, and biometric matching systems. Different architectures, same structural vulnerability. In automated immigration systems, the database often becomes the first version of the factual record. If the data is wrong, every downstream recommendation built on it can appear internally consistent while being factually false.
That is why rectification occupies a chapter of its own.
Rectification is not an administrative courtesy. In the context of algorithmic immigration systems, it is a legal defense tool — one that operates upstream of the final decision, at the level of the data that produced it. If explanation opens the black box, rectification cuts the wire between the error and the outcome. This chapter maps the legal framework for that work on both sides of the Atlantic, with the precision that operational use requires.
I. The European framework: rectification as a direct legal right
GDPR, Regulation (EU) 2016/679, Articles 16 and 17 EU AI Act, Regulation (EU) 2024/1689, Article 86
The clearest legal foundation for rectification in European immigration practice is Article 16 of the GDPR, which states that the data subject has the right to obtain from the controller, without undue delay, the rectification of inaccurate personal data concerning them, and — taking account of the purposes of the processing — the right to have incomplete personal data completed, including by means of a supplementary statement.
That right applies wherever the GDPR applies to immigration-related data processing — that is, wherever a controller established in the EU or processing data about persons in the EU is operating outside the strictly defined law-enforcement framework of Directive 2016/680. It is directly applicable to USCIS-equivalent processing by EU Member State immigration authorities, to Schengen Information System records affecting individual legal status, and to any high-risk AI system operating under the AI Act that draws on personal data in its assessment or classification functions.
Article 86 of the AI Act creates a complementary instrument. It provides that persons subject to decisions made by or with the assistance of a high-risk AI system — decisions that produce legal effects or similarly significant effects — have the right to obtain clear and meaningful explanations of the role that the AI system played in the decision-making procedure. That explanation right is the mechanism that makes Article 16 actionable in the algorithmic context: explanation identifies which inputs the system used, which outputs it generated, and where in the data pipeline the factual error sits. Without the explanation, the lawyer may know the decision was wrong but cannot identify which specific record to correct. With it, the rectification request becomes targeted and legally grounded.
In practice, the layered EU strategy is: demand explanation under Article 86 AI Act, identify the erroneous input, demand rectification under Article 16 GDPR, and if the controller fails to act, escalate through supervisory authority complaint under Article 77 GDPR or judicial review under Article 79 GDPR. That sequence is legally coherent and practically executable. The response timeline under Article 12 GDPR is one month from receipt of the request, extendable by a further two months in complex cases with notification to the data subject.
II. Why rectification in immigration is not administrative housekeeping
A common misunderstanding is to treat data correction as a clerical function — relevant only when the error is obvious and the stakes are low. In immigration law, the opposite is true. Very small data errors can produce very large legal consequences when they enter an automated decision environment.
A wrong date of birth can create a false identity merge — the system treats your client as the same person as someone with an enforcement history. A dismissed charge still recorded as active can elevate a risk score. A biometric mismatch preserved in a long-term record can generate repeated secondary screening at every subsequent border encounter. An erroneous translation in an asylum narrative can trigger a fraud flag that follows the case through every subsequent review.
The GDPR does not distinguish between small and large inaccuracies when the legal consequences are serious. Article 16’s right to rectification applies whenever personal data is inaccurate — the magnitude of the error is not a threshold condition. What matters legally is whether the inaccuracy affects the person’s legal position. In immigration, it almost always does.
This is why rectification in the European framework is rights-protective rather than merely administrative. The legal basis for the controller’s use of inaccurate data collapses when the data subject invokes Article 16. A high-risk AI system operating under the AI Act cannot be lawfully deployed against a person on the basis of data that the controller knows to be inaccurate. The system’s sophistication does not cure the underlying data problem.
III. The US framework: Privacy Act, FOIA, and the SORN architecture
Privacy Act of 1974, 5 U.S.C. § 552a Freedom of Information Act, 5 U.S.C. § 552
The United States has no general federal equivalent to GDPR Article 16. The primary instrument for record access and correction in the federal immigration context is the Privacy Act of 1974, codified at 5 U.S.C. § 552a, which must be understood with precision — both in what it provides and in what it does not.
Section 552a(d) gives an “individual” the right to request amendment of a record in a system of records that the individual believes is not accurate, relevant, timely, or complete. The agency must acknowledge the request within ten days, investigate, and either make the correction or explain why it refuses and what further review procedures are available. The statutory definition of “individual” under section 552a(a)(2) — a citizen of the United States or an alien lawfully admitted for permanent residence — means that the full amendment right does not extend to all noncitizens in immigration proceedings. Many asylum seekers, visa holders, and undocumented individuals fall outside the statutory definition.
That limitation must be stated clearly and never overstated in client counseling or litigation. It does not, however, mean that no records route exists. DHS’s FOIA process — available regardless of citizenship — permits records requests that can reveal what data the government holds, what systems it appears in, and what specific errors the record contains. FOIA and Privacy Act requests can be combined: the Privacy Act request establishes the amendment claim for qualifying individuals, while the FOIA request provides the disclosure mechanism for all requesters regardless of status.
IV. The SORN map: identifying the right system before filing
DHS System of Records Notices — dhs.gov/system-records-notices-sorns
Rectification work in US immigration requires knowing which system holds the relevant record. Under the Privacy Act, federal agencies maintain Systems of Records organized through System of Records Notices published in the Federal Register. DHS maintains a comprehensive SORN index at dhs.gov. For immigration rectification purposes, the practitioner needs to identify the specific system before filing.
The primary systems relevant to immigration AI rectification are the following. The Alien File, Index, and National File Tracking System — DHS/USCIS/ICE/CBP-001, published at 78 FR 69864 (Nov. 21, 2013) — is the core immigration record for each individual in contact with US immigration authorities. It covers the A-File and all associated records. This is the first system to target in any rectification effort.
The External Investigations system — DHS/ICE-009, published at 75 Fed. Reg. 404 (Jan. 5, 2010) — covers investigative case files maintained by ICE Homeland Security Investigations, including records held in the Investigative Case Management system. The 2021 Privacy Impact Assessment for ICM (DHS/ICE/PIA-045) confirms that investigative case file records are retained for 20 years and biometric records within ICM for 75 years. DHS/ICE-009 is subject to law enforcement exemptions under 5 U.S.C. § 552a(j)(2) and (k)(2), which may limit access and amendment rights for active or closed enforcement matters.
The Analytical Records system — DHS/ICE-018, published at 86 FR 15246 (Mar. 22, 2021) — covers ICE’s analytical data environment, which consolidates and aggregates data from multiple source systems including ICM, for use with advanced analytical tools that may incorporate AI and machine learning. This is the system most likely to hold pattern-analysis outputs, AI-assisted risk assessments, and aggregated data profiles used in enforcement prioritization.
The Fraud Detection and National Security Records system — DHS/USCIS-006, published at 77 FR 47411 (Aug. 8, 2012) — covers FDNS records including records generated by Pangaea Text and ATLAS screening activity in the asylum context examined in Chapter 20.
The Nonimmigrant Information System — DHS/CBP-016, published at 80 FR 13398 (Mar. 13, 2015) — and the broader CBP TECS system cover entry and exit records, including records generated by facial recognition events in the biometric entry-exit program examined in Chapter 21.
Knowing which system holds the relevant error is not a preliminary formality. It is the core of the strategy. A Privacy Act request that does not identify the applicable system of records may produce a response that is technically responsive but operationally useless — confirming that no records exist in the systems searched when the relevant record sits in a system the request did not identify.
V. Law enforcement exemptions — the constraint and its limits
Many DHS immigration enforcement systems are subject to law enforcement exemptions under 5 U.S.C. § 552a(j)(2) or (k)(2), which allow agencies to exempt certain categories of records from the access and amendment provisions of the Privacy Act. DHS/ICE-009 and DHS/ICE-018 both carry such exemptions. DHS/USCIS-006 carries a law enforcement exemption for FDNS records tied to fraud investigations.
Those exemptions constrain the amendment right. They do not transform inaccurate data into lawfully usable data. That distinction is the most important point in this section.
An exemption may prevent the lawyer from obtaining immediate statutory amendment of a specific record. It does not prevent the lawyer from building a constitutional argument that the government is continuing to rely on a demonstrably inaccurate record in a way that materially affects liberty or legal status. Where the government uses false data to justify detention, deny a benefit, or impose an enforcement consequence, the due process argument becomes stronger precisely because the normal correction mechanism has been blocked by exemption. The government cannot have it both ways: it cannot invoke law enforcement privilege to prevent correction and simultaneously invoke the accuracy of its records to justify adverse action.
This is the key advocacy principle: an exemption narrows the administrative rectification path. It does not eliminate the constitutional and administrative law arguments that inaccuracy in government decision-making generates.
VI. The practical rectification workflow
A disciplined rectification approach in US immigration practice follows a sequence that moves from record access to targeted correction to escalation.
The first step is to obtain the records. A combined FOIA and Privacy Act request — identifying the A-File under DHS/USCIS/ICE/CBP-001 and any additional systems where records are likely to exist based on the enforcement context — establishes the documentary baseline. The request should be specific about the information sought: all records relating to the individual, including records in ICM, FDNS-DS, analytical systems, and any watchlist or targeting system records. Where the client’s status limits Privacy Act amendment rights, the FOIA request provides the disclosure pathway.
The second step is to identify the exact factual error. The error must be specific and demonstrable: a wrong birth date, a wrong alien number, an incorrect criminal disposition, a merged identity profile, a misattributed enforcement event, an incorrect travel document status, a stale record not updated to reflect a changed legal circumstance. Abstract claims that the system produced a wrong result are legally weaker than specific, documentable factual errors in identifiable data fields.
The third step is to connect the error to a legal consequence. The rectification argument is not that the data is technically inaccurate in isolation. It is that the inaccurate data contributed to a specific adverse outcome — a detention recommendation, an elevated risk score, a fraud flag, a bond denial, a removal order — and that correcting the data would change or undermine the basis for that outcome.
The fourth step is to seek amendment or correction through the available channel. Where Privacy Act amendment rights apply, file the amendment request with the specific system custodian identified in the SORN. Where exemptions limit that route, file an administrative complaint, preserve the issue in the case record, and prepare the due process or APA argument for escalation.
The fifth step, if the agency continues relying on demonstrably false data after being put on notice, is to frame the issue as arbitrary agency action under 5 U.S.C. § 706. An agency that knows its factual basis is inaccurate and continues to act on it is not exercising lawful discretion. It is acting arbitrarily — and arbitrary agency action is reviewable.
VII. Rectification as a defense strategy, not administrative cleanup
The practical lesson of this chapter is one of timing and posture.
In algorithmic immigration systems, the most consequential legal intervention is often not the argument made at the final hearing. It is the correction made before the algorithmic recommendation has time to harden into an administrative presumption. A data error that is corrected before it reaches the risk score, before it generates a detention recommendation, before it produces a fraud flag, is an error that never becomes a case.
A successful rectification effort does not only improve a single file. It can clean the client’s digital profile across all future interactions with the systems that share that data — across the A-File, ICM, FDNS-DS, and the analytical environment — because DHS’s own SORN framework requires that data shared between systems carry the restrictions applicable to its original source. A correction in the originating system propagates, at least in principle, to the systems that received the data through routine sharing.
That is why rectification is a defense tool first and an administrative cleanup second. The lawyer who identifies the data error before the hearing and corrects it changes the evidentiary foundation of the case. The lawyer who discovers it after the denial is fighting a harder battle against a harder record.
Next: Chapter 23 — Challenging an algorithmic immigration decision: the complete checklist.
Leave a Reply