Yemi Osei-Bonsu spent the first two weeks of her new job as CIO of Macon-Bibb County, Georgia, reading the AI strategies of three other jurisdictions. One came from the City of Los Angeles: a sprawling document covering seventeen departments, $80 million in planned AI investment, and a 24-person AI governance committee. One came from a federal agency, a dense framework aligned with OMB guidance, requiring authority-to-operate processes and FedRAMP-authorized tools. One came from the State of Georgia, a statewide strategy with coordination requirements across 80 agencies. All three were thoughtful documents. None of them were usable as templates for a county government with 2,200 employees, a $287 million annual budget, and an IT department of 14 people. Yemi spent a third week figuring out what an AI strategy for her actual context looked like. This lesson is what she learned.

Why Context Is Not Just a Caveat

Every AI strategy guide eventually says something like "adapt these principles to your context." That phrase does real work and gets skipped over. The differences between government contexts are not minor variations in organizational culture. They are fundamental differences in legal authority, procurement capacity, data infrastructure, workforce capability, and political accountability that change which AI applications are feasible, which governance structures are required, and how fast things can move.

A federal CIO operating under OMB Circular A-130 and the Federal Information Security Management Act (FISMA) lives in a different regulatory world than a county IT director whose primary legal constraints are state procurement law and the county charter. A military organization classifying AI systems under DoD AI principles operates differently than a civilian health department subject to HIPAA. A 50,000-employee state agency with a dedicated AI center of excellence has different options than a 200-employee municipal court system. The strategic choices that work for one will not work for the others, and imitating a framework built for a different context is one of the most common ways government AI strategies fail.

Government comes in many forms. Size matters. Mission matters. Security requirements matter. Budget constraints matter. Each context creates its own set of constraints and its own set of opportunities, and a strategy that ignores either half will not survive contact with the organization it was written for. Fitting your strategy to your context is a necessary condition for execution. It is not a sufficient one: a well-fitted strategy still fails when leadership changes, funding lapses, or the data turns out to be worse than anyone admitted. Fit buys you the chance to execute, not the outcome.

The Four Axes of Context

Government contexts vary along four axes. Knowing where your organization sits on each axis tells you which parts of the generic AI strategy playbook apply and which need to be rewritten. Work through all four before you write a word of strategy, because a misjudgment on any one of them will show up later as a commitment you cannot keep.

Scale and resource capacity

Scale determines what you can build versus what you must buy, and what governance structures are proportionate. A large federal agency, meaning 10,000 or more employees and an IT budget above $500M, can afford a dedicated AI program office, a multi-year capability-building investment, and the staff to conduct internal fairness testing. A mid-sized state agency of 2,000 to 10,000 employees, with an IT budget between $50M and $200M, can afford focused capability in one or two areas but needs to leverage shared services and pre-built tools for everything else. A small local government under 500 employees, with an IT budget below $10M, realistically cannot build AI capabilities internally at all. Its strategy must be built around off-the-shelf tools, cooperative procurement vehicles, and possibly shared services from a regional or state-level provider.

Yemi's 14-person IT department is not going to train a machine-learning model. That is not a failure; it is a constraint that shapes the strategy. Every AI initiative in Macon-Bibb County will use commercial off-the-shelf software or services procured through Georgia's statewide contract vehicle. The county's data team is two people. Every AI application that requires significant data preparation will take longer than equivalent applications at larger agencies. The strategy has to be honest about that rather than quietly assuming the constraint away.

Regulatory environment

Federal agencies face the most prescriptive AI regulatory environment. OMB Memorandum M-24-10 established agency-specific requirements for AI governance, including mandatory chief AI officer designations, annual inventories of rights-impacting and safety-impacting AI uses, and specific minimum practices for high-risk AI. Federal contractors and grant recipients have additional obligations depending on the program. Defense agencies operate under DoD AI principles with additional requirements for autonomous and semi-autonomous systems.

State and local governments are not subject to OMB guidance, which applies only to federal agencies, but many states have enacted their own AI laws. As of mid-2026, more than 25 states have passed legislation or issued executive orders governing AI use in state agencies. County and municipal governments in those states are often subject to state requirements, especially when they administer federally funded programs such as Medicaid, housing assistance, or child welfare, which carry their own federal oversight requirements. Being outside OMB's scope is not the same as being outside every requirement, and treating it that way is how small jurisdictions get surprised.

The practical implication: before your strategy names a specific AI application, your general counsel needs to have confirmed the legal framework that applies to it. A predictive-risk scoring tool for child welfare decisions has a different legal profile in a state that has enacted an algorithmic accountability statute than in a state with no equivalent legislation. That does not mean the application is right in one state and wrong in the other. It means the governance documentation, the testing requirements, and the public disclosure obligations are different, and your counsel is the one who tells you which set you are under.

Mission type

Mission type shapes both the value of AI and the risk profile of AI failures. Agencies whose missions involve high-volume, routine transactions, such as processing tax returns, issuing licenses, or managing benefit applications, have strong AI opportunities in automation and classification, with error costs that are real but typically correctable. Agencies whose missions involve consequential decisions about individuals, such as parole recommendations, disability determinations, or child removal, have AI opportunities in decision support but face much higher error costs and much more stringent fairness and explainability requirements. Agencies whose missions involve physical safety, such as transportation safety, environmental emergency response, or public health, face both high-value AI applications and potentially life-safety consequences of AI failures.

Yemi's county includes the Macon Water Authority, which manages drinking water infrastructure for 95,000 residents. An AI tool that optimizes pipe maintenance scheduling is a high-value, moderate-risk application, because errors cause service disruption rather than immediate health risk. But an AI tool that determines when a water-quality alert should be issued is a safety-impacting application that requires human review at every decision point and a clear incident response protocol. The mission-type analysis tells you which applications get standard governance and which get enhanced governance, before anyone has fallen in love with a product.

Data maturity and legacy systems

AI applications are only as good as the data they run on. Agencies with modern, well-maintained data infrastructure, meaning cloud-hosted, well-documented, and built on consistent data standards, have far more AI options than agencies running on 20-year-old enterprise systems with siloed data, poor documentation, and no API access. Most government agencies sit somewhere between those extremes, and many have pockets of excellent data quality next to pockets of unusable data within the same organization.

Federal agencies feel this most acutely, because decades of data sit scattered across legacy systems that were never designed to talk to each other. Cleaning and integrating that data is a major effort and an unavoidable prerequisite. The strategic implication holds everywhere: a data maturity assessment, covering what data exists, in what form, with what quality, accessible by what means, should precede the AI applications roadmap. The applications your strategy commits to in years one and two should be ones for which you have adequate data today. Applications that require data you do not have yet should be sequenced after the data infrastructure investments that will create it.

Reading Your Tier: Federal, State, Local

The three tiers of government face genuinely different trade-offs, and each tier has advantages it routinely forgets to use. Yemi found it useful to read the tier grid before reading anyone else's strategy, because it explained why the Los Angeles document and the federal framework were built the way they were. Neither was wrong. Both were answers to a different question than hers.

Two worked illustrations show the tier logic in motion. A large federal benefit agency built its strategy around 18 months of data integration before any pilots ran. The timeline looks slow next to a startup, but the agency is building capability that will sustain AI across the whole organization for decades. A state labor ministry took the partnership route instead, pairing with a state university computer science program so that students work on state AI projects as dissertation or capstone work. The state gets access to talent it could not hire; the university gets real problems to solve.

At the local end, a city with 50 employees cannot build AI from scratch, but it can sequence. Year one, automate the permitting process with a consultant. Year two, build on that same team to add pothole detection. By year three the city has working systems and a small amount of durable local capability. A county with 150 people follows the same logic through a university partnership, putting graduate students on a single project, running it on cloud tools, and stopping there. One finished project beats a portfolio of intentions.

Size Shapes the Operating Model

Tier tells you which rules apply. Size tells you what kind of machine you can run. Large organizations, meaning roughly 1,000 employees and up, have the scale to build specialized teams, hire and retain specialists, fund significant infrastructure, and generate enough internal demand to keep those people busy. What they pay for it is complex governance with many stakeholders, slow decision-making, harder change management because there are more people to change, and silos that resist being broken.

The operating model that fits that profile is a center of excellence: a centralized AI team serving the whole organization, providing governance, building capability, and maintaining standards. Pair it with a federated execution model so that the central team sets the standards and individual departments innovate within them. Invest in data strategy as a foundational commitment rather than a project, and build the change management infrastructure that large-scale change actually needs, meaning training programs, communication plans, and support for staff whose work changes. One 10,000-person federal agency staffed its center of excellence with 50 people spanning data science, engineering, governance and training, then let departments build while the center provided oversight.

Small organizations, in the range of 100 to 300 employees, invert every one of those trade-offs. They are agile and can change direction quickly, decisions move through fewer layers, people wear multiple hats, and the community is tight enough to build genuine enthusiasm. What they lack is the ability to justify a single-function specialist role, budget for infrastructure, operational bandwidth, and deep expertise. The strategic responses follow directly: hire generalists rather than specialists, someone who is part analyst, part engineer and part program person, because you need the flexibility more than the depth. Lean on external partners through universities, regional resources, consultants and shared services. Aim at outcomes rather than capabilities, because a small organization cannot build "data science capability" but it can run one project that delivers a clear result. And keep the solution simple: complex enterprise systems do not fit, while simple open-source tools, cloud services and existing platforms do.

Defense and Civilian Missions

The last split is mission character rather than tier or size. Defense organizations are security-first and highly compartmentalized, with strict compliance requirements that shape what data can move, which tools can be authorized, and who can see a model's outputs. Civilian organizations are mission-first, operating under public accountability, open process expectations and transparency requirements that mean decisions get explained in public and records get requested. Both are legitimate operating environments, and each carries obligations the other does not.

The strategic consequence is that you cannot lift a civilian agency's transparency-heavy AI strategy into a defense context, or a defense agency's compartmentalization-heavy strategy into a civilian one, without breaking something important in each. Defense prioritizes security. Civilian prioritizes transparency and public benefit. Write the strategy for the accountability regime you actually operate under, and be explicit in the document about which regime that is, so nobody downstream has to guess.

Three Scenarios

Look at how context shapes strategy through three concrete scenarios, each one drawn from a different point on the axes above.

Scenario one: a large state agency. A state Department of Labor with 8,000 employees and a modernized unemployment insurance system. The agency has a mature data warehouse, a small data science team, and a relatively recent policy framework. The strategic opportunity is significant: AI-assisted claim routing, fraud detection, and automated eligibility verification are all technically feasible with current data infrastructure. The governance requirement is also significant, because unemployment determinations are rights-impacting, meaning the state's algorithmic accountability obligations apply. The strategy should include a phased rollout: fraud detection first at lower rights-impact, then claim routing at medium impact, then eligibility decision support at the highest impact with the most extensive testing and human-review requirements. The governance framework should be built once and applied to all three phases, not rebuilt for each.

Scenario two: a mid-sized county government. This is Yemi's situation. Small IT staff, no data science capability, a mix of modern and legacy systems, procurement through statewide contract vehicles. The realistic strategy is three to five off-the-shelf AI tools over three years, each selected from vendors with existing state contracts, each scoped to a well-defined problem with good data quality, each with a named county employee as system owner. The governance framework should be a two-page checklist adapted from state guidance, not a custom framework. The county should designate one person, probably Yemi, as AI coordinator rather than standing up a full AI governance board. Proportionality matters: a governance structure designed for a federal agency will be abandoned by a 14-person IT department within a year.

Scenario three: a small municipal department. A city parks department with 80 employees. IT support comes from the city IT department, which does not have AI expertise. The realistic AI strategy is one or two tools: a scheduling optimization tool for parks events, widely available, SaaS-based and low in governance complexity, and possibly a chatbot for resident inquiries about parks programming, available through the city's existing web platform vendor. The strategy for this department is a two-page document naming those two tools, their implementation timeline, their vendor source, who is responsible for each, and how complaints will be handled. Anything more elaborate is not a strategy. It is a wish list that nobody will implement.

What Adapting Actually Looks Like

Adapting an AI strategy framework to your context is not about lowering your ambitions. It is about making commitments you can actually keep, with the resources you actually have, within the legal framework that actually applies to you. Adaptation is a set of explicit substitutions, each one written down, rather than a general intention to be realistic.

For Yemi, adaptation meant dropping the AI governance board, because with 14 people total in IT a governance board is three or four of them meeting monthly, which is not proportionate. She substituted a single-page governance checklist that she reviews for every new AI tool. She dropped the AI center of excellence and substituted a relationship with Georgia Technology Authority's statewide AI support team, which provides technical review capacity on a consulting basis. She dropped the multi-year capability-building roadmap and substituted two tool-specific pilot plans for fiscal year one, with explicit decision points at six months. She kept the equity commitment: outcomes disaggregated by race and income for any tool affecting resident services. That is non-negotiable regardless of agency size.

That last item deserves emphasis, because it is the one thing on the list that does not scale down. Equity obligations do not shrink with headcount. The requirement to track outcomes disaggregated by race, income and language applies whether the agency has 200 employees or 20,000. It is a constitutional and statutory floor, not an aspiration that large agencies can afford and small ones cannot. Proportionality governs how you organize the work. It does not govern whether the protection applies.

The other half of adaptation is leverage. Most strategies written under constraint spend all their energy on what the organization cannot do and never name what it uniquely can. Federal agencies have budget and interagency coordination that nobody else has. States have university partnerships and the ability to serve their local governments. Local governments have direct community relationships and decision cycles measured in weeks. Write your context advantages into the strategy explicitly, in their own section, and build at least one initiative that only your context makes possible.

The right strategy for your agency is the one your agency will actually execute. A perfect strategy nobody implements is worth less than a modest strategy everybody owns. Organizations that succeed with AI build strategies that fit their reality, meaning their size, their constraints and their opportunities, and they do not pretend to be something they are not.

Anti-Patterns

• The one-size-fits-all strategy. The temptation is to copy another government's AI strategy and adapt it lightly. It fails because the other government's strategy was designed for their context, and yours is different. Use other strategies as inspiration, never as templates, and design for your specific context.
• Overambition for size. A small government tries to execute a large-government strategy, or a large government tries to execute a startup's speed. The strategy does not fit reality, you overcommit, you miss, and you lose the credibility you need for the next attempt. Be realistic about what your size can execute: small means sequencing ruthlessly, large means centers of excellence and governance.
• Ignoring context constraints. You skip past budget, hiring or compliance limits on the assumption that you will overcome them. You will not. Constraints are real, and a strategy that ignores them does not execute. Account for them explicitly and build inside them, which is harder and far more honest.
• Not leveraging context advantages. You focus so hard on constraints that you miss the opportunities unique to your position, and the advantages go unused. Identify them explicitly and build strategy that spends them.
• Treating context fit as a guarantee of success. A context-appropriate strategy removes one large category of failure. It does not remove funding lapses, leadership turnover, vendor collapse, or data that turns out to be unusable. Fit is a precondition, not an outcome, and a strategy that treats it as an outcome stops looking for the next problem.
• Assuming outside OMB means outside everything. State and local agencies are not covered by federal OMB memoranda, and some read that as freedom from AI obligations entirely. State statutes, state executive orders, and the federal requirements attached to federally funded programs all still apply. Ask counsel which apply to you rather than reasoning from what does not.
• Scaling equity commitments down with headcount. Governance structures should be proportionate to capacity. Disaggregated outcome tracking for tools that affect residents is not a governance structure; it is a floor. Cutting it because the agency is small is the one economy that is not available.

Practice Prompts

• Context analysis. Define your government context in writing: federal, state or local? What size? What mission? What compliance environment? What constraints? What advantages? One page, no hedging.
• Constraint assessment. Name your biggest constraint among budget, talent, infrastructure and compliance. For each, write one sentence on how it changes your strategy, not just that it exists.
• Leverage identification. List your context advantages: partnerships, community relationships, resources, decision speed. Pick one and design an initiative that only your context makes possible.
• Strategy adaptation. Take a general AI strategy framework and adapt it for your specific context. What changes? What stays the same? Write the adapted version as a set of explicit substitutions, in the pattern of drop this, substitute that.
• Realistic roadmap. Given your constraints and advantages, write the roadmap you can actually deliver. Small organizations should be able to point at one project per year and defend it.
• The tier grid. Fill in the federal, state and local grid from this lesson for your own organization, then hand it to someone outside IT and ask whether the constraints column matches their experience of working with you.

Reflection

Look at the last strategy document your organization produced, for AI or anything else. Which parts of it were written for your context, and which were inherited from a document written somewhere else? Where did it commit to a governance structure your headcount cannot sustain, and where did it commit to an application your data cannot yet support? If you assessed your context honestly today, which of those commitments would survive?

Then ask the harder question. Which of your context advantages has your organization never once spent? Most agencies can name their constraints in seconds and their advantages not at all. If a peer agency in your tier asked you what they could learn from your position, what would you tell them, and why is it not already in your strategy?

Glossary

• Center of Excellence (CoE). A centralized team of AI specialists serving an entire large organization, providing governance, building standards, and supporting individual departments.
• Federated model. A governance approach in which a central team sets standards and provides oversight while departments innovate and execute within those standards.
• Context-appropriate. Strategy tailored to fit the specific constraints, size, mission and environment of an organization rather than imported from a different one.
• Sequencing. Phasing projects over time, often one per year, rather than attempting everything at once. Essential for small organizations.
• External partnerships. Using universities, contractors and shared services to access expertise you cannot hire internally.
• Rights-impacting use. An AI use that affects a person's legal rights, benefits, access or opportunities, and which therefore carries heightened testing, review and disclosure obligations.
• Cooperative procurement vehicle. A statewide or regional contract that lets smaller jurisdictions buy from pre-negotiated terms without running their own full procurement.

Related Lessons

• Developing an Organizational AI Strategy gives you the general framework this lesson teaches you to adapt.
• AI Maturity Assessment is the instrument for placing your organization on the data maturity and capability axes honestly.
• Prioritization Frameworks for Government AI covers how to choose among the applications your context actually permits.
• Stakeholder Management and Communication covers explaining a proportionate strategy to leaders who read someone else's more ambitious one.
• Strategy Capstone: Building Your AI Strategy is where the context work in this lesson becomes a finished document.

Closing

There is no universal AI strategy for government. There is AI strategy adapted to a federal context, a state context, a local context, a large organization, a small organization, a defense mission, a civilian mission. Your job is adapting the principles to your specific situation, and doing it in writing, where the substitutions can be argued about and defended.

Assess your context. Understand your constraints. Identify your advantages. Design a strategy that fits your reality and name the things you are choosing not to do. That is how you build an AI strategy that actually executes, and it is what Yemi produced in her third week when she stopped reading other people's documents and started writing her own.

Key Takeaways

• Context is not a caveat; it determines feasibility. Scale, regulatory environment, mission type, and data maturity are four axes along which government contexts differ fundamentally. The strategy that works for a 50,000-person federal agency will not work for a 200-person county office, and imitating frameworks from different contexts is one of the most common ways government AI strategies fail.
• Governance structures must be proportionate to capacity. A 14-person IT department cannot sustain a 24-person governance committee. Proportionate alternatives, meaning a single coordinator, a checklist, and a statewide support relationship, produce better outcomes than elaborate frameworks that get abandoned.
• Confirm the legal framework before naming specific applications. Federal agencies face OMB M-24-10 requirements. State and local agencies face varying state laws, plus federal requirements for programs they administer. General counsel needs to confirm the applicable framework before the strategy commits to specific AI tools.
• Mission type determines the governance tier for each application. Routine transaction processing gets standard governance. Rights-impacting decisions about benefits, licensing and eligibility get enhanced governance with fairness testing and human review. Safety-impacting decisions such as water quality and emergency response get maximum governance with human review at every decision point.
• Data maturity assessment precedes the applications roadmap. Commit in years one and two only to applications for which you have adequate data quality today. Applications requiring data you do not have should be sequenced after the infrastructure investments that will create it.
• Size selects the operating model. Large organizations run centers of excellence with federated execution and real change management infrastructure. Small organizations hire generalists, sequence one project per year, buy simple tools, and aim at outcomes rather than capabilities.
• Small agencies have real options through shared services and cooperative procurement. Statewide contract vehicles, regional consortiums, and shared services from state-level providers give small jurisdictions access to AI tools without building internal capacity. The strategy should name the procurement vehicle, not just the tool category.
• Spend your context advantages, not just your constraints. Federal budget and interagency coordination, state university partnerships, local community proximity: each tier has leverage it routinely fails to write into the strategy at all.
• Equity obligations do not scale with agency size. The requirement to track outcomes disaggregated by race, income, and language applies regardless of whether the agency has 200 employees or 20,000. This is a constitutional and statutory floor, not an aspirational goal for large agencies.

Frequently Asked Questions

Our leadership read another jurisdiction's AI strategy and wants ours to look like it. How do I push back?

Show them the axes rather than arguing about ambition. Put your headcount, IT budget, data maturity and legal framework next to the other jurisdiction's, and let the gap make the argument. Then bring a proportionate substitution for each element they liked: a coordinator instead of a board, a checklist instead of a framework, a statewide support relationship instead of a center of excellence. Leaders rarely want the specific structure. They want the assurance the structure was supposed to provide, and a proportionate version delivers that assurance in a form you can staff.

We are a county. Does OMB M-24-10 apply to us?

OMB guidance applies to federal agencies. That does not settle the question for you, because your state may have its own AI legislation or executive order, and any federally funded program you administer carries its own oversight requirements. The answer comes from your general counsel reviewing your specific programs, not from the fact that a federal memorandum names federal agencies. Ask before your strategy names an application, not after.

How small is too small to have an AI strategy at all?

No organization is too small, but the appropriate document gets very short. For an 80-person department, the strategy is two pages naming the one or two tools, the timeline, the vendor source, the responsible person, and the complaint process. That is a real strategy. What is too small is the capacity to sustain a governance board, a center of excellence, or a multi-year capability roadmap, and writing those in anyway is how a strategy becomes a wish list.

Should we build or buy?

Scale mostly answers this for you. Below roughly 500 employees with an IT budget under $10M, building is not realistic, so the strategy should be built around off-the-shelf tools and cooperative procurement. In the mid-sized range you can build focused capability in one or two areas and buy everything else. Only at large federal scale does building broadly become a defensible default, and even there the data integration work usually has to come first.

What is the single most common way these strategies fail?

Committing to applications the data cannot support yet. It looks like an ambition problem and it is really a sequencing problem. Run the data maturity assessment first, put the applications with adequate data today in years one and two, and place everything else after the infrastructure investment that creates its data. The second most common failure is a governance structure nobody has the headcount to staff.

How do we handle the defense and civilian split if we sit in both worlds?

Write the strategy to the stricter regime for each specific system rather than picking one posture for the whole organization. A compartmentalized system carries the security-first obligations; a public-facing system carries the transparency and public accountability obligations. State in the document which regime governs each system, because the ambiguity is what causes trouble later, not the difference itself.