Theodora Mwangi-Castellanos was the deputy director of a county innovation office, and she had a federal AI memo on her desk that did not apply to her. OMB Memorandum M-24-10 governs federal agencies, and her county was not one. Yet her county was deploying AI faster than most federal agencies: a chatbot for the assessor's office, a predictive tool for code enforcement, automated translation for public notices, and a vendor system the sheriff's office had bought without telling anyone. The county had no AI policy at all, no chief AI officer, no inventory, and a patchwork of state laws that changed every legislative session.

Her job was to build governance for a level of government the major federal framework simply does not reach, in a legal landscape that is a moving target. She could not copy the federal playbook. She had to adapt it. This lesson is about AI policy for state and local government: why these governments cannot inherit federal frameworks, what they can borrow, how the jurisdictional map actually works, and how to build governance at the level of government closest to residents. State and local agencies run the schools, the police departments, the benefits offices, the courts, and the permitting counters where AI touches people most directly, and they do it with smaller budgets, thinner technical staff, and a far more variable legal environment than federal agencies face.

Why Federal Frameworks Do Not Simply Transfer

Federal AI guidance, including M-24-10, the NIST AI Risk Management Framework, and related executive direction, is valuable, and it was written for federal agencies with federal resources. State and local governments differ in ways that matter for policy design. They are not bound by OMB memoranda. They have their own constitutions, statutes, and procurement laws. They typically have a fraction of the technical staff. And they sit much closer to residents, which raises both the impact and the visibility of every AI decision. A small city cannot stand up a chief AI officer, a governance board, and an impact-assessment apparatus modeled on a cabinet department. It needs governance scaled to its size.

What does transfer is the conceptual core. The NIST AI Risk Management Framework is explicitly voluntary and was designed for adoption by any organization, including state and local governments, and its functions of govern, map, measure, and manage scale down without losing their meaning. The two-tier risk idea in M-24-10, distinguishing rights-impacting from safety-impacting uses, is a sound classification scheme regardless of jurisdiction. Theodora's strategy was to borrow the frameworks' logic while right-sizing their machinery, which is a very different exercise from adopting a federal document and hoping a county can operate it.

The Jurisdictional Map

The constitutional structure allocates authority across federal, state, and local government, and each level has power to regulate within its jurisdiction. Tribal nations hold sovereign authority of their own. The result is overlapping and sometimes conflicting frameworks rather than a single national scheme, which is why practitioners describe the environment as a patchwork rather than a hierarchy. The source for this lesson frames the scale plainly: managing AI policy across 50 states, thousands of cities and counties, and multiple sovereign tribal nations is a materially harder coordination problem than federal governance, not an easier one.

The consequences are concrete rather than theoretical. A data use case that is lawful in one state may not be in another. A vendor that satisfies federal procurement requirements may not satisfy a particular city's requirements. A system that complies with federal guidance may still violate state law. And the enforcement mechanisms differ by level: state attorneys general can bring civil actions to enforce state law, while at local level the consequences run through permits, fines, and interruption of operations. Reputational damage and loss of resident trust attach at every level and are the hardest to repair.

Federal law is supreme when it genuinely conflicts with state or local law, but that principle is narrower in practice than it sounds. States can generally impose requirements stricter than federal ones, states cannot prevent federal agencies from complying with federal law, and the real question in almost every case is whether the federal requirement preempts the state or local one at all. Preemption occurs when federal law expressly forbids state regulation, or when the federal scheme is so comprehensive that state regulation would interfere with it.

In AI governance specifically, the source states that preemption is rare, because federal AI requirements are still developing, Congress has not expressly preempted state AI regulation, and most federal and state requirements are complementary rather than conflicting. Treat that as the current reading rather than a permanent feature, because it is precisely the kind of statement a single act of Congress or a single court decision can reverse. The practical instruction, which does not change either way, is that you cannot assume a federal requirement excuses you from a state or local one. That is a question for counsel about your specific system, in your specific jurisdiction, at the time you ask it.

The State Landscape

As of the source's writing in early 2026, the state landscape is fragmented and developing quickly, with different states taking visibly different approaches. Some have enacted broad AI governance legislation. Some have addressed AI only within specific sectors. Many have not legislated on AI at all, and that group is shrinking. Any list of which states have what is out of date faster than a training document can be revised, so use the shape of the landscape below to know what to look for and confirm the current text with counsel in each state where you operate.

California has been the most active, with several measures the source groups as rights-focused: requirements that users be told when they are interacting with a bot, requirements for disclosure of AI use in government, and a proposal, not an enacted law, to require impact assessments for automated decision systems. The rights-focused pattern is what matters for policy design: systems affecting fundamental rights attract assessment, transparency, and human oversight obligations that go beyond what federal guidance requires. Note that a bot-disclosure requirement is stated broadly here and its real scope is defined by statutory text rather than by summary, so confirm the actual scope with counsel before designing to it.

Colorado has enacted AI governance legislation centered on bias testing and fairness requirements, human review of algorithmic decisions, and transparency and disclosure mandates. The source also names New York, Illinois, Massachusetts, and Texas as states with AI legislation, each with somewhat different requirements. Sector-specific requirements appear across many states in healthcare, criminal justice uses such as risk assessment and sentencing recommendations, employment and hiring, and lending and housing decisions. These sectoral rules matter disproportionately to state and local agencies because those are exactly the functions state and local government performs.

One point in the source deserves to be carried exactly as it errs, which is toward caution. It states that federal agencies operating in states with AI requirements must comply with state law, covering bias testing, transparency, human oversight, and data protection where state requirements exceed federal ones. Whether a state requirement actually binds a federal agency is a genuinely contested legal question that turns on the specific requirement and the specific agency. The source's own instruction is the right one, and it is the instruction to follow: assess which state requirements are relevant to your systems, determine whether they apply to you, and consult agency legal counsel about your compliance obligations rather than deciding the question yourself.

Local Ordinances and Municipal Governance

Cities and counties increasingly establish AI requirements through ordinance, and local rules can be stricter or looser than the state law above them. San Francisco has restricted government use of facial recognition and has adopted algorithmic bias audit requirements. New York City has adopted requirements addressing transparency and accountability for AI used in hiring, scoped in practice to employers rather than to AI generally, which is a good illustration of why the scope of a local rule matters as much as its existence. The source additionally names Boston, Portland, Seattle, and Denver among cities that have passed algorithmic accountability measures. Confirm the current text and scope of any of these before designing to it.

The pattern across municipal approaches is more durable than any individual ordinance. Local rules concentrate on algorithmic bias and discrimination, transparency and disclosure to residents, human oversight of algorithmic decisions, impact assessments for higher-risk systems, and a resident right to an explanation and an appeal. If you are drafting local policy rather than complying with someone else's, that list is a reasonable table of contents, and it maps closely onto what the federal frameworks ask for at much larger scale.

The right to an explanation and an appeal deserves particular attention at local level, because this is where the abstraction becomes a person at a counter. A resident denied a permit, flagged by a code enforcement tool, or routed by a benefits triage system is standing in a building owned by the government that deployed it, and the appeal path is a real desk with a real person behind it rather than a portal. That proximity is why local rules concentrate on explanation and appeal more than federal frameworks do, and why a local policy that specifies who a resident talks to, and how quickly, is doing more governance work than a longer document that does not.

Tribal Sovereignty

Tribal nations hold sovereign authority to govern AI within their territories, and this is not a variation on state or local governance. Tribes are recognized as distinct political entities, and tribal law applies to tribal members and on tribal lands. Some tribes are developing AI governance frameworks, and this is an emerging area rather than a settled one. Tribal authority extends to restricting AI deployment affecting tribal members, requiring data sovereignty so that tribal data remains on tribal lands, requiring consultation before AI deployment, and establishing tribal AI governance standards of their own.

For any agency whose systems touch tribal nations, the source's statements are unambiguous and should be carried in full: consultation is required for AI systems affecting tribal nations, tribal data must be handled according to tribal governance requirements, and federal agencies cannot override tribal governance authority. The practical failure to avoid is treating tribal governance as a special case inside a standard compliance process, which reverses the relationship. Build tribal consultation into the governance framework from the beginning, and invest in the relationships before you need something, because consultation initiated at the point of deployment is not consultation.

Building the Update Mechanism Before the Rules

The defining feature of state and local AI policy is that the legal landscape moves. State AI statutes, state privacy laws, public-records and open-meeting laws that bear on AI transparency, and state procurement codes that govern how AI enters the building all change from session to session. A static policy in a moving legal environment is obsolete the moment a new statute passes, and the obsolescence is silent: nothing alerts a county that its policy no longer matches the law.

Theodora's first policy move was therefore not a rule but a process. She established a standing legal-monitoring function that tracked her state's AI-related legislation and adjusted county policy as the law moved, and she built that mechanism before she built the rules it would maintain. This sequencing is counterintuitive and it is correct. Any government operating across more than one jurisdiction needs someone accountable for tracking requirements, maintaining a current inventory of them, and identifying conflicts and gaps, whether that is a centralized compliance function or a distributed one with central coordination.

Building a Right-Sized AI Policy

Theodora's county policy adapted the federal logic into machinery a county could actually operate. Each of the four components below was chosen because it works with generalist staff and no dedicated AI specialists, which is the binding constraint at this level of government and the one most policy templates quietly assume away. Notice what is absent from the list as much as what is on it: there is no standing board, no impact-assessment methodology requiring statistical expertise, and no in-house testing capability. Every element either uses staff the county already has or pushes the obligation onto a vendor who does have the expertise.

A single intake and inventory

The foundation was an AI use-case inventory reached through a single intake path: no county agency could procure or deploy an AI system, including a vendor feature inside other software, without registering it. This directly addressed the sheriff's-office problem of AI entering through procurement with no central visibility. The inventory is the cheapest and highest-value governance artifact a small government can build, it requires no data scientists, and it is the first thing any oversight body, journalist, or public-records requester will ask for.

Right-sized risk classification

The county adopted the rights-impacting and safety-impacting categories, simplified to its own context. A use case affecting residents' benefits, housing, employment, or liberty, or their physical safety, triggered heightened review, and everything else received a light-touch check. Because the county had no large governance staff, heightened review meant a small cross-functional panel drawn from county counsel, IT, the relevant department head, and a civil rights or equity representative, rather than a standing board with a full-time chair it could never have funded.

Vendor governance as the center of gravity

Unlike large federal agencies that build some systems in house, state and local governments buy nearly all of their AI. That makes procurement the primary point of control. Theodora's policy embedded AI requirements directly into county contracts: vendors had to disclose how their systems worked, permit fairness testing, support explainability, and accept audit rights. For a government that buys rather than builds, the contract clause is the governance mechanism, and a policy that does not reach the vendor does not reach the AI.

Transparency tuned to local law

State public-records and open-meeting laws often give residents more direct transparency rights at local level than they have federally, and their exact scope varies by state. Theodora's policy leaned into that: a public-facing register of the county's significant AI systems, plain-language notice when AI informs a decision affecting a resident, and a path to human review. Proximity to residents is a transparency obligation and an opportunity rather than only a risk, and a local government that publishes first is rarely the one that ends up explaining itself afterwards.

Designing Systems That Work Across Jurisdictions

Agencies operating in more than one jurisdiction have three broad design responses, and most mature programs use a combination rather than choosing one outright. Each has a genuine disadvantage, and the disadvantages rather than the advantages are what determine which combination fits a given organization, because every one of these approaches works in a demonstration and they diverge only under sustained operation. Read the fourth column of the table below first, then decide which cost your organization is actually equipped to carry over several years and several legislative sessions.

The most-stringent approach is the right default and it has a limit worth stating clearly, because it is often taught as though it always works. It resolves differences of degree, where one jurisdiction demands more of the same thing. It cannot resolve a genuine incompatibility, where one jurisdiction requires an approach that another forbids, and no amount of additional rigor will satisfy both. When you hit a true conflict, the answer is legal counsel and possibly a jurisdiction-specific design, not a more elaborate universal one.

The common resolvable case looks like this. A federal requirement obliges you to retain log data for security purposes while a state requirement restricts retention of the same data. The resolution is a jurisdiction-specific data handling design that satisfies both, typically through tighter access restriction, stronger separation, and a shorter retention period for the affected jurisdiction's data. What makes it work is that the two requirements point in different directions on a shared dimension rather than contradicting each other outright. Document the analysis and the reasoning as carefully as the design, because the documentation is what you will show a regulator later.

Coordination and Shared Capacity

No single state or local government can track this landscape alone, which is why the coordination infrastructure matters as much as the policy. Professional associations do most of the practical work: the National Association of State Chief Information Officers convenes state CIOs on AI governance, the International City and County Management Association supports coordination among local governments, and the Council of State Governments works on interstate policy coordination. Participating in them is how a small government learns about emerging requirements early, contributes to standard-setting, and gains access to model policies it would never have the staff to draft.

Two other mechanisms shape behavior across levels. Federal grant programs can condition funding on compliance with federal priorities, including AI governance expectations, which aligns incentives without requiring preemption. And states coordinate directly with each other through multi-state model legislation efforts, regional standard-setting, and information sharing about implementation problems. Federal agencies can support all of this by sharing what federal requirements actually mean in practice and helping states understand the compliance implications of drafts before they are enacted rather than after.

Inside your own organization, the choice is between centralized compliance management and federated responsibility. A centralized function tracks requirements across all relevant jurisdictions, maintains the inventory of them, identifies conflicts and gaps, and coordinates implementation. A federated arrangement makes each regional office or department responsible for compliance in its own jurisdiction, with a central function providing guidance, training, coordination, and shared documentation. Federated responsibility is workable and it demands stronger central coordination rather than less, because distributed accountability without a shared view of requirements is simply accountability nobody holds.

The last coordination mechanism is the most underused, which is talking directly to the jurisdictions writing the rules. Requirements are frequently ambiguous rather than hostile, and the drafters often have no visibility into what a clause does to an organization that operates in many other jurisdictions at the same time. Engaging lets you clarify ambiguous language before you have designed to the wrong reading, request relief where requirements create a genuine conflict, participate in the requirement-setting process while the text is still moving, and build the working relationships that make every later interaction faster. Agencies that treat this as part of compliance rather than as lobbying anticipate requirements instead of reacting to them.

Designing for the Resource Reality

The hardest constraint at state and local level is capacity. Theodora's county had no AI specialists and no budget to hire any. Her policy was built to be operable by generalists: checklists instead of bespoke assessments, a small cross-functional panel instead of a standing board, contract clauses instead of in-house testing labs, and shared resources wherever they existed, including model policies and pooled expertise available through professional associations and state-led AI task forces. The design principle was that a governance process nobody has time to follow is not governance at all.

Pooled capacity is the part most easily overlooked, and it is what makes the arithmetic work at this scale. Model policies, shared contract language, common risk classification schemes, and peer experience with specific vendors are all things one government drafts and many can reuse, and the professional associations and state AI task forces exist substantially to move them around. A county that writes its own version of everything is spending its scarcest resource, which is generalist staff attention, on work another county has already done. Adapting a peer's document and citing where it came from is faster, more defensible, and easier to update when the law moves.

Six months after adoption, the county's AI register listed eleven systems that had previously been invisible, including the sheriff's-office tool, each with a risk classification, a named department owner, and contract-based audit rights for the vendor systems. None of that required a data science team. It required a policy engineered for a county's actual constraints rather than copied from a framework written for Washington. Right-sizing was not a compromise on rigor. It was the only version of the policy that would ever have been used.

Anti-Patterns

Assuming federal compliance is sufficient

The reasoning is that federal law is supreme, so satisfying federal requirements must satisfy everything below them. The result is deploying a system in a state whose requirements you never assessed, and learning about the gap from a state attorney general's office rather than from your own counsel. The consequences run to investigation, mandated remediation, litigation, and public criticism. The fix is a systematic assessment of which state and local requirements reach your systems, done with counsel, and repeated when either the systems or the requirements change.

Building a separate configuration for every jurisdiction

Trying to honor every local variation with its own system variant produces a portfolio nobody can maintain. The failure surfaces on the day a security vulnerability requires patching every variant at once, and the engineering team discovers it cannot. Distinguish genuinely unique requirements from variations that modular configuration can absorb, satisfy the most stringent standard wherever that is possible, and use configuration management rather than separate code branches to handle the differences that remain.

Assuming jurisdictions will resolve conflicts for you

It is comfortable to assume that states and localities coordinate enough that incompatible requirements will not arise. They can and do arise, and when they do you are caught between them with no mechanism to appeal. Engage in coordination actively rather than waiting: join the professional associations, participate in multi-jurisdiction forums, report conflicts to the jurisdictions creating them, and help drafters understand what their requirement does to an organization operating across many jurisdictions at once.

Treating tribal governance as a compliance category

Running tribal nations through the same process used for cities treats sovereign authority as an administrative variation. The concrete failure is deploying a system affecting tribal members without consultation, then facing a demand that it be shut down, with the relationship damaged for years afterward. Understand tribal sovereignty as sovereignty, establish consultation processes with tribal governments before you need them, build tribal requirements into the framework from the beginning, and invest in relationships with tribal leadership as a standing commitment rather than a project task.

Writing the policy before the update mechanism

A policy written against this session's statutes and never revisited will quietly stop matching the law, and nothing in the ordinary course of business will surface the mismatch. The tell is a policy document whose last revision date predates the most recent legislative session in a state where you operate. Stand up the legal-monitoring function first, name who owns it, and give it a defined cadence and a route to trigger policy amendment.

Mistaking a right-sized process for a weak one

The opposite failure is also common: a small government copies a federal apparatus wholesale, cannot staff it, and ends up with an impressive document nobody follows, which is worse than a modest process that is actually executed. A checklist completed every time beats an impact assessment template completed twice. Scale the machinery to the staff who will operate it, and judge the policy by whether the inventory is complete rather than by how closely it resembles a cabinet department's.

Practice Prompts

These are drafting exercises for a real jurisdiction rather than thought experiments, and each of them should end with a document someone else could act on. Involve your counsel from the beginning, particularly on anything touching preemption, applicability, or tribal consultation, because those are questions of law about your specific circumstances rather than questions of policy design. Work them in the order given, since each one supplies an input the next assumes you already have.

1. Build the inventory first. List every AI system and every AI procurement in flight across your government, including features inside software bought for another purpose, with the owning department, the decision it informs, the residents it affects, and the vendor for each. Note how many you did not know about before you started.
2. Map the requirements that reach you. For each jurisdiction where you operate, identify AI-specific requirements, privacy requirements, public-records and open-meeting obligations, and procurement rules that govern how AI enters the building. Mark which of your inventoried systems each one touches, and take the open legal questions to counsel rather than resolving them yourself.
3. Design your update mechanism before your policy. Name who tracks legislative and regulatory change in each relevant jurisdiction, at what cadence, using what sources, and by what route a change becomes a policy amendment rather than a note in a file.
4. Draft the AI clauses for your standard contract: vendor disclosure of how the system works, permission for fairness testing, explainability support, audit rights, and notification when the vendor materially changes the model. Then take them to your procurement office and find out which ones your existing contract vehicles can actually carry.
5. Work a conflict end to end. Take a federal or state retention requirement and a stricter state restriction on the same data, and design a jurisdiction-specific handling approach that satisfies both. Then construct a case where the requirements are genuinely incompatible rather than merely different in degree, and write down what you would do instead.

Reflection

Start with the question Theodora could not answer on her first day: how many AI systems does your government run right now, and who could tell you without asking around? Then extend it to the systems that arrived as features inside other software, which is how the sheriff's-office tool entered her county. The distance between what you can enumerate and what is actually running is the real starting point for any policy, because a governance framework can only reach what someone has counted.

Then consider the capacity question honestly. Look at the governance process you have written or are about to write, and identify who in your organization will execute each step, by name and with their other duties attached. If any step has no name against it, or the name belongs to someone with no time, that step will not happen, and the policy will be judged later on the gap between what it promised and what it did. Right-sizing is not lowering the bar. It is putting the bar where someone can actually reach it every time.

Glossary

• Preemption. The doctrine under which federal law displaces conflicting state or local law, either expressly or because the federal scheme is comprehensive enough that state regulation would interfere. Rare in AI governance so far, and states can generally impose stricter requirements.
• Tribal sovereignty. The authority of tribal nations to govern within their territory as distinct political entities. Tribal law applies to tribal members and on tribal lands, and federal agencies cannot override it.
• State attorney general. A state's chief legal officer, who enforces state law and can bring civil actions against entities that violate it, including AI governance requirements.
• Rights-impacting and safety-impacting. The two-tier risk classification drawn from federal guidance, distinguishing uses that affect residents' rights, benefits, or liberty from those that affect physical safety. Adaptable at any scale of government.
• Algorithmic accountability. The principle that entities deploying AI are answerable for its decisions and their impacts, increasingly embedded in state and local requirements.
• Data residency. A requirement that data remain within a specified geography, appearing in state, local, and tribal governance to address data protection and sovereignty concerns.
• AI use-case inventory. A single register of every AI system in use, with owner, purpose, risk classification, and vendor. The lowest-cost and highest-value governance artifact available to a small government.
• Most stringent standard. A design approach that satisfies the strictest requirement across all jurisdictions in one system, effective for differences of degree and unable to resolve genuine incompatibilities.

Related Lessons

• Federal/State/Local AI Alignment takes up the alignment problem across levels of government directly and complements the county-level view here.
• Multi-Level Government AI Governance goes further into governance structures that span jurisdictions.
• Drafting Agency AI Policies covers the policy-writing craft that this lesson right-sizes for smaller governments.
• Navigating the Federal AI Landscape covers the federal frameworks whose logic state and local governments borrow.
• International AI Governance extends the multi-jurisdiction problem beyond national borders.

Closing

Fragmentation in this area is not going away, and it is not purely a defect. A federal system lets jurisdictions experiment, adapt requirements to local conditions, and move faster than a single national framework would. The cost of that design is a compliance burden that falls hardest on the governments with the least capacity to carry it, which is exactly backwards from where the capacity sits. Good state and local AI policy is the work of closing that gap with process design rather than with staff a county does not have.

Theodora's county ended up with eleven previously invisible systems on a register, each with an owner, a risk classification, and audit rights where a vendor was involved. That outcome came from four unglamorous decisions: build the update mechanism before the rules, make registration mandatory and unavoidable, put the governance requirements in the contract because that is where the AI comes from, and scale every process to the generalist staff who would actually run it. None of it required a data science team, a chief AI officer, or a federal budget. It required a policy designed for the government that had to operate it.

Key Takeaways

• State and local governments cannot simply inherit federal frameworks. They are not bound by OMB memoranda, they have their own laws and procurement codes, they have far less technical staff, and they sit closer to residents. Borrow the logic and right-size the machinery.
• Federal supremacy does not mean federal sufficiency. Preemption in AI governance is rare so far, states can generally go stricter, and whether a given federal requirement excuses a state or local one is a question for counsel about your specific system rather than an assumption.
• Tribal nations are sovereign, not another compliance category. Consultation is required for systems affecting tribal nations, tribal data follows tribal governance, and federal agencies cannot override tribal authority. Build consultation in from the beginning.
• The legal landscape moves every session. Stand up a standing legal-monitoring function before writing the rules it will maintain, because a static policy in a moving environment goes stale silently.
• A single intake and inventory is the highest-value, lowest-cost artifact. Requiring every deployment to register, including vendor features inside other software, catches the AI that procurement otherwise hides.
• Vendor contracts are the primary control. State and local governments buy rather than build, so disclosure, fairness testing, explainability, and audit-rights clauses are where governance actually happens. A policy that does not reach the vendor does not reach the AI.
• The most stringent standard is the right default with a real limit. It resolves differences of degree and cannot resolve genuine incompatibility, where the answer is counsel and a jurisdiction-specific design rather than more universal rigor.
• Local transparency law is an opportunity. Public-records and open-meeting rights support a public AI register, plain-language notice, and a path to human review, and publishing first beats explaining afterwards.
• Design for the staff you have. Checklists, small cross-functional panels, contract clauses, and shared resources from associations such as NASCIO, ICMA, and CSG make governance operable by generalists. A process nobody can follow is not governance.

Frequently Asked Questions

Does M-24-10 apply to our county or city?

No. OMB memoranda govern federal agencies, and state, local, and tribal governments are outside their reach. What is useful about M-24-10 is its logic, particularly the distinction between rights-impacting and safety-impacting uses, which is a sound classification scheme at any scale. The NIST AI Risk Management Framework is explicitly voluntary and was designed for adoption by any organization, so it can be adopted directly. Borrow the concepts and build machinery your staff can actually operate.

Do state AI requirements bind a federal agency operating in that state?

That is a legal question rather than a policy question, and it turns on the specific requirement and the specific agency. The source for this lesson takes the cautious position that federal agencies operating in states with AI requirements must comply with state law covering bias testing, transparency, human oversight, and data protection. It also gives the right instruction, which is to assess which requirements are relevant, determine whether they apply, and consult agency legal counsel. Do not resolve this one from a training document.

What do we do when two jurisdictions genuinely conflict?

First, check whether the conflict is real. Most apparent conflicts are differences of degree, where one jurisdiction wants more of what another wants less of, and a jurisdiction-specific design with tighter access, stronger separation, or a shorter retention period satisfies both. A genuine incompatibility, where one jurisdiction requires what another forbids, cannot be engineered away by being stricter. Take it to counsel, document the analysis and the reasoning, and consider whether different jurisdictions need different approaches.

We have no AI staff at all. Where do we start?

With the inventory, because it costs nothing but attention and everything else depends on it. Require every AI deployment and procurement to register, including features inside software bought for another purpose, and record the owner, the decision it informs, the residents affected, and the vendor. Then add contract clauses, because you buy rather than build. Then adopt a simple two-tier risk classification with a small cross-functional panel for the higher tier. None of those steps requires a specialist.

How should we handle AI that arrives inside software we already bought?

Treat it as a deployment, because it is one. The sheriff's-office system in Theodora's county entered exactly that way, through procurement and outside anyone's visibility. The controls that work are a registration requirement that explicitly covers embedded AI features, procurement review that flags AI capability arriving inside other purchases, and contract terms requiring the vendor to notify you when they add or materially change AI functionality in a product you are already running.