For most counties the EU AI Act is not the law that applies. It is the most fully worked-out public example of two ideas a county can use anyway: classify AI by what it is used for, and tell people when AI is involved.
This is the third of four posts on how the Integrated Requirements Methodology, the method behind the Encephalon Enterprise AI Governance Practice and Tools, relates to the standards and laws local governments are asked about. Part 1 covers the NIST AI RMF, part 2 covers ISO/IEC 42001, and part 4 covers Florida law and Chapter 119.
One difference from the other three posts: the method maps to NIST, ISO and Florida’s records law. It does not claim any mapping to the EU AI Act. What follows is about ideas the method shares with the Act, not compliance with it. Nothing here is legal advice. County attorneys decide how the Act applies to their operations. Encephalon has not yet run this method under a public-sector contract.
Who the Act reaches
Article 2(1) of Regulation (EU) 2024/1689 says the Act applies to, among others:
“(a) providers placing on the market or putting into service AI systems or placing on the market general-purpose AI models in the Union, irrespective of whether those providers are established or located within the Union or in a third country; (b) deployers of AI systems that have their place of establishment or are located within the Union; (c) providers and deployers of AI systems that have their place of establishment or are located in a third country, where the output produced by the AI system is used in the Union”
Article 3 defines a deployer as “a natural or legal person, public authority, agency or other body using an AI system under its authority…” A US county that uses an AI tool is a deployer in that sense. It is not established in the Union, so point (b) does not reach it. Point (c) could, but only where the system’s output is used in the Union. A county drafting permit correspondence or summarizing its own meeting minutes for its own residents is not ordinarily in that position. We would not say it can never happen. A county that ran a service used by people in the EU, or that built and offered an AI system to others, would need to look again, and its attorney is the right person to make that call.
One misreading worth heading off: Article 2(4) says the Act applies neither to public authorities in a third country nor to international organisations in a specific setting, “where those authorities or organisations use AI systems in the framework of international cooperation or agreements for law enforcement and judicial cooperation” with the Union or its Member States, and only where that third country or organisation provides “adequate safeguards” for individuals’ rights and freedoms. It is a narrow carve-out for that cooperation, not a general exemption for foreign governments. A county that relies on it for ordinary administrative AI is relying on the wrong paragraph.
The dates have also moved. The Act entered into force on 1 August 2024. Regulation (EU) 2026/1744 of 8 July 2026, the Digital Omnibus on AI, amended Article 113 so that the high-risk rules in Chapter III, Sections 1 to 3 (other than Article 6(5)) apply from 2 December 2027 for systems classified through Annex III, and from 2 August 2028 for systems classified through Annex I. Anything you read that gives 2 August 2026 as the Annex III date is out of date.
Borrowing one: classify by intended use
The Act does not sort AI by technology. Article 6(2) says “AI systems referred to in Annex III shall be considered to be high-risk,” and Annex III is a list of uses. Point 5(a) is the one a county will recognize:
“AI systems intended to be used by public authorities or on behalf of public authorities to evaluate the eligibility of natural persons for essential public assistance benefits and services, including healthcare services, as well as to grant, reduce, revoke, or reclaim such benefits and services”
Article 6(3) then allows that an Annex III system is not high-risk “where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making.”
The method’s risk tiering works on the same instinct, applied to the workflow instead of to the system. Its third tier, Consequential, is assigned when an output participates in a determination about an identified person, parcel, filing, case, account or employee, or touches material the office holds exempt or confidential. An eligibility decision about a resident lands there, as it would under Annex III. Article 6(3) lets a provider exempt a listed system that does not materially influence the outcome, but only where one of four listed conditions is met, never for a system that profiles people, and the provider, not the user, makes and documents that call. A human who can overturn the output is not one of the conditions: under the Act, human oversight is a duty of a high-risk system, not a way out of it. The method asks a similar question of the county’s own workflow, and its only reviewer-driven move is from the top, Reserved tier down to Consequential.
The difference matters too. The Act attaches obligations to a system’s intended purpose, set largely by its provider. The method attaches the tier to the county’s use of it, so the same product can sit in different tiers in different offices. A county owns its workflow. It does not own the vendor’s statement of intended purpose. Article 25(1)(c) underscores the same point from another angle: a deployer that changes the intended purpose of an AI system that was not high-risk, so that it becomes high-risk under Article 6, is treated under the Act as the provider of a high-risk system. The obligation follows the use, not the label the vendor shipped it with.
Borrowing two: name the human who oversees
For high-risk systems, Article 26(2) says “Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support.” That sentence is a good test for any county AI policy. Oversight assigned to “staff” or “the department” fails it. The method’s human-acceptance authority answers it by decision class, and at the Consequential tier the office’s own officer, head or board authorizes the use in writing and a deputy the office names accepts each output.
Article 27(1) goes a step further for deployers that are bodies governed by public law, requiring them to assess the impact on fundamental rights before deploying most Annex III systems. A county is ordinarily not bound by that article. The discipline of assessing before deploying, and writing it down, carries over directly.
Borrowing three: transparency the public can see
Article 50(1) requires providers to design systems that interact directly with people so that “the natural persons concerned are informed that they are interacting with an AI system,” unless that is obvious. Article 50(4) requires deployers of systems that generate text “published with the purpose of informing the public on matters of public interest” to disclose that the text was AI-generated, with an exception where the content “has undergone a process of human review or editorial control and where a natural or legal person holds editorial responsibility for the publication of the content.”
That exception is a useful design for a county. It does not ban AI drafting of public notices. It asks whether a named person stood behind the text. The method’s second tier, Work product, asks the same thing: when an AI-assisted output enters a county file or leaves the originating office, a named owner in the releasing office accepts it before release.
For public-authority deployers of Annex III systems, Article 49(3) requires registration in an EU database (other than critical-infrastructure systems; under Article 49(4), law enforcement and migration uses are registered in a non-public section), and Article 71(4) makes that information “accessible and publicly available in a user-friendly manner.” The method’s public AI registry design comes from the same idea: a resident should be able to see which decisions AI participates in without filing a request.
What not to borrow
The Act’s penalties and conformity assessment machinery were written for a single market with regulators to enforce them. A county policy that copies them imports enforcement language nobody will enforce. Borrow the classification logic and the transparency duties. Leave the rest.
One line from the Act does travel as a caution. Article 26(6) requires deployers of high-risk systems to keep automatically generated logs for “at least six months, unless provided otherwise in applicable Union or national law.” In the United States, how long a public body keeps AI logs is not a design choice. It is generally set by state records law, and in Florida that law has a lot to say, which is the subject of part 4.
The whitepaper covers the governance gap and the Kimball roots of the method. Book a 30-minute discovery call with the founding team to test your county’s current AI uses against a use-based tiering.
Primary sources cited
- Regulation (EU) 2024/1689 (Artificial Intelligence Act), OJ L, 12.7.2024. Articles 2(1), 2(4), 3(4), 6(2), 6(3), 25(1)(c), 26(2), 26(6), 27(1), 49(3), 49(4), 50(1), 50(4), 71(4), 113; Annex III point 5(a). https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Regulation (EU) 2026/1744 of 8 July 2026 (Digital Omnibus on AI), OJ L, 24.7.2026, amending Article 113 of Regulation (EU) 2024/1689. https://eur-lex.europa.eu/eli/reg/2026/1744/oj
