Federal Agencies: One AI Intake Model Targets Results in 90 Days

Federal agencies do not usually lose control of artificial intelligence because a first pilot fails. They lose control because the first success invites a second project, a third vendor, a separate data path and another approval process—until an initiative designed to improve mission delivery becomes a costly collection of disconnected experiments. The most important message from CDW Government’s recent AWS Summit Washington, D.C. discussion is therefore not that agencies need more AI pilots. It is that they need a repeatable operating model capable of converting pilots into enterprise AI results within 90 days.
Asim Iqbal and Aaron Chapman framed the issue in terms federal IT leaders know well: artificial intelligence creates a coordination problem before it becomes a model-selection problem. Individual program offices may have sensible reasons for pursuing a generative AI assistant, a document-processing workflow, a predictive analytic tool or an emerging agentic capability. Yet those local decisions can create agency-wide fragmentation when they are not connected through common governance, security, data and procurement practices.
The proposed answer is deceptively straightforward: establish one front door for every AI use case. That means one intake process, one visible portfolio, clear risk tiers, a designated decision authority and a renewal mechanism that checks whether deployed systems are still delivering value safely. In practical terms, it is a way to make AI governance an accelerator for responsible adoption rather than a late-stage compliance obstacle.
For federal agencies facing pressure to modernize services, improve workforce productivity and demonstrate responsible stewardship of taxpayer funds, the distinction matters. Enterprise AI cannot be governed successfully as a collection of isolated software purchases. It must be operated as a managed capability spanning mission ownership, data stewardship, cybersecurity, acquisition, infrastructure and workforce readiness.

---

Background: The Pilot-to-Production Gap in Federal AI​

The federal AI conversation has progressed far beyond basic experimentation. Agencies are testing and deploying AI for knowledge retrieval, customer support, document classification, cybersecurity operations, software development, scientific research and administrative automation. Generative AI has lowered the barrier to prototyping, allowing teams to produce impressive demonstrations quickly.
That speed is valuable, but it can obscure the difficult work required to scale. A proof of concept can use a narrowly curated dataset, a limited population of users and a temporary cloud environment. A production system must deal with identity, access management, records obligations, auditability, model updates, data retention, operational monitoring and changing mission needs.
This is the pilot-to-production gap. It is where organizations discover that an apparently successful AI tool lacks a sustainable owner, its data quality is inconsistent, its security assessment is incomplete or its vendor agreement does not cover the system’s evolving role. A pilot may show that a model can answer questions. It does not automatically establish that the model should influence a mission workflow, access sensitive records or remain deployed after its initial funding ends.
Federal policy also reinforces the need for disciplined scaling. Current Office of Management and Budget direction emphasizes accelerated adoption while retaining safeguards for privacy, civil rights, civil liberties, security and accountability. It also calls on agencies to make better use of existing investments, avoid duplicative spending, identify accountable AI leadership and maintain AI use case inventories.
That framework should not be interpreted as an instruction to create a sprawling new bureaucracy. The stronger interpretation is that agencies should make AI decisions visible, proportionate and repeatable. A low-risk internal productivity experiment should not face the same process as an AI capability affecting eligibility, benefits, law enforcement, health, employment or another consequential outcome. But both should enter the same governance ecosystem.

Why AI Sprawl Arrives So Quickly​

AI sprawl rarely begins with reckless behavior. It begins with urgency.
A program executive sees a backlog of documents and wants extraction and summarization. A customer-service leader wants an assistant for a public-facing portal. A cybersecurity team wants better alert triage. Developers want coding assistance. A research division wants retrieval-augmented generation over technical reports. Each initiative may be defensible on its own merits.
The problem emerges when each group selects its own tools, models, implementation partners and oversight process. The agency may then inherit multiple contracts for similar capabilities, inconsistent security configurations and no authoritative view of where agency data is being processed.

Fragmented ownership creates fragmented accountability​

When responsibility is spread across program offices without a common framework, ownership becomes ambiguous. The business team may assume IT is responsible for security. IT may assume the program office owns model performance and workflow decisions. Procurement may treat the purchase as a conventional software subscription even when the service changes model versions, data flows or supporting infrastructure over time.
The result is a familiar but dangerous question: Who is accountable when the AI system produces a harmful, inaccurate or insecure outcome?
Enterprise AI governance must answer that question before deployment. The accountable official should be tied to the mission outcome, not merely the technology platform. Technical teams can operate the service, security teams can assess controls and data teams can enforce stewardship rules, but a mission owner must remain responsible for how AI is used in the work itself.

Duplicate procurement undermines efficiency​

The cost of AI fragmentation is not limited to license fees. Every distinct deployment can introduce separate integration work, separate identity configurations, separate support arrangements, separate user training and separate risk reviews. Those costs compound quickly.
An agency may also lose leverage in vendor negotiations if multiple offices buy overlapping services independently. More importantly, it can lose the ability to reuse components that should be shared: approved data connectors, prompt-management practices, evaluation methods, secure cloud environments and common retrieval services.
A central intake process does not require a single vendor or a single model. In fact, imposing one tool everywhere can create its own risks. The real objective is to create deliberate reuse where reuse makes sense, while preserving enough technical flexibility for mission-specific needs.

Shadow AI expands the attack surface​

The rise of embedded AI in enterprise software makes visibility even harder. AI features now appear in productivity suites, customer relationship management platforms, developer tools, security products, cloud services and specialized line-of-business applications. An agency can be using AI without having procured a standalone “AI platform.”
That reality makes a traditional inventory based only on major contracts inadequate. Agencies need to understand:

• Which systems include AI-enabled features
• Which models, services or APIs support those features
• What data the systems can access
• Where prompts, files, outputs and telemetry are retained
• Who can enable or configure advanced AI functions
• Which vendors and subcontractors participate in the service chain
• How the system is monitored, changed and retired

Without this visibility, an agency cannot accurately manage risk, cost or compliance. It cannot even reliably answer the basic question of how much AI it is operating.

---

The One-Front-Door Model​

The strongest idea in the CDW Government discussion is the creation of a single intake and renewal process for AI use cases. This is not simply a service desk form with the word “AI” added to it. It is an operating mechanism that connects demand, risk, funding, architecture and accountability.
Every proposed AI use case should enter through the same front door, whether it is a small internal assistant, a purchased software feature, a custom-built model application or a major mission system modernization effort.

What the intake should capture​

The intake must be short enough that teams will actually use it, yet structured enough to support triage. Agencies should avoid turning the front door into an essay contest. The early objective is to identify what is being proposed, why it matters and what level of scrutiny it requires.
A useful intake includes the following information:

• Mission problem: What operational pain point, service gap or decision bottleneck is the system intended to address?
• Expected outcome: What measurable improvement is expected in time, cost, quality, accuracy, accessibility, resilience or mission throughput?
• Business owner: Which official owns the process and outcome?
• User population: Who will use the system, and who may be affected by its outputs?
• AI function: Is the tool summarizing, classifying, predicting, generating content, recommending actions, automating workflow steps or acting through connected tools?
• Data profile: What data types will be accessed, processed, stored or transmitted?
• Decision role: Is the AI advisory, assistive, automated or involved in a potentially high-impact decision?
• Technology path: Is the proposal based on an existing enterprise platform, a new acquisition, a custom build or an embedded feature?
• Initial risk factors: Does it involve sensitive information, external users, regulated records, critical operations or automated action?
• Success measures: What baseline exists, and how will the agency determine whether the use case has earned continued investment?

This intake should create a living portfolio record rather than a one-time approval artifact. As the project advances, the record becomes the place where the agency stores decisions, risk findings, performance measures, approvals, renewal dates and retirement plans.

Triage must be risk-based, not identical for every project​

The most common governance mistake is applying the same heavy process to every AI use case. That delays harmless productivity tools, frustrates users and encourages teams to work around official channels. It also consumes expert attention that should be focused on systems with significant mission or public impact.
A better model uses clearly defined tiers.
The specific categories will vary across agencies. The principle should remain stable: the level of governance should match the anticipated impact of the use case.

Governance boards should decide, not merely discuss​

A governance board that meets monthly to exchange updates will not solve AI sprawl. The board needs authority to make timely decisions, resolve conflicts and establish reusable patterns. It should be small enough to act and broad enough to see the consequences of each decision.
At minimum, the core operating group should connect:

• The Chief AI Officer or designated AI leader
• The CIO organization
• The CISO and security engineering teams
• The Chief Data Officer or data governance lead
• Privacy, civil liberties and legal counsel where applicable
• Acquisition and contracting leadership
• Enterprise architecture
• Records management and information governance
• Mission program owners
• Finance or portfolio management representatives

Not every member needs to review every low-risk request. The value of the governance structure lies in having a defined escalation path. Routine items should move rapidly through standardized approval patterns, while sensitive cases should reach the officials capable of accepting or rejecting risk.

---

A Practical 90-Day Enterprise AI Plan​

The phrase “building enterprise AI in 90 days” should be treated carefully. No agency can responsibly transform every legacy system, resolve every data issue or deploy every desired AI workload in three months. That would be an unrealistic promise.
What an agency can do in 90 days is establish the operating foundation that turns scattered pilots into an enterprise program. The goal is not to complete the entire AI journey. It is to create a governed pathway through which useful work can continue safely and visibly.

Days 1–30: Establish control and visibility​

The first month should focus on gaining a reliable picture of the current environment. Agencies should resist the temptation to begin by buying a new AI platform. They first need to know what they already have, what projects are underway and where the highest-value opportunities sit.
Key actions include:

1. Name executive sponsorship and accountable leadership.
   Confirm the AI leader, executive sponsor and governance decision rights. Clarify which body approves high-risk uses and who can accept residual risk.
2. Launch an AI discovery sprint.
   Identify active pilots, production systems, planned purchases, embedded AI features and departmental experiments. Include work occurring in cloud environments, software-as-a-service platforms and contractor-managed systems.
3. Create the single intake form and triage criteria.
   Keep the initial form practical. Its purpose is to route projects properly, not to require every control document on day one.
4. Define interim data-use rules.
   Establish plain-language guidance on what users may enter into approved AI tools, what data is prohibited, and how confidential, controlled or personally identifiable information must be handled.
5. Select two to four priority use cases.
   Prioritize projects with clear mission value, manageable data scope, committed owners and measurable outcomes. Avoid choosing only flashy chatbot concepts.
6. Set baseline metrics.
   Record the current time to complete the targeted work, accuracy level, backlog volume, user satisfaction, cost or other relevant baseline. Without this step, claims of AI value will be difficult to substantiate later.

The most valuable output of the first 30 days is an enterprise AI portfolio view. It may not be perfect, but it should be credible enough for leadership to see duplication, risk concentration, vendor overlap and promising opportunities.

Days 31–60: Build reusable guardrails and delivery patterns​

The second month shifts from discovery to enablement. This is where governance earns credibility by making it easier—not harder—for teams to deliver.
Agencies should establish reusable assets such as:

• Approved architecture patterns for internal generative AI, retrieval-augmented generation and API-based applications
• Identity and access management standards
• Logging, audit and observability requirements
• Data classification and connector requirements
• Vendor due-diligence questionnaires
• Contract language for transparency, model changes, data handling, incident response and exit planning
• Evaluation templates for accuracy, grounding, safety and mission-specific performance
• Human oversight requirements for higher-risk systems
• Standard user guidance and training materials

A shared AI sandbox can be particularly effective when it is operated with defined boundaries. Rather than allowing every office to create an unmanaged experiment, the agency can provide an approved environment with controlled access, known data restrictions and preconfigured monitoring.
This approach enables faster experimentation while avoiding the proliferation of untracked environments. It also gives security, data and architecture teams a chance to learn from real usage patterns before production systems scale.

Days 61–90: Deliver measurable results and institutionalize renewal​

The final month should produce visible outcomes. At least one or two selected use cases should reach a meaningful operational milestone, such as a controlled production release, a documented evaluation or a validated workflow redesign.
The results should be measured against the baseline created in the first month. Useful metrics may include:

• Reduction in processing time
• Lower backlog volume
• Improved first-pass document accuracy
• Reduction in repetitive service requests
• Faster incident triage
• Increased employee satisfaction
• Improved accessibility or response consistency
• Cost avoidance from retiring duplicate tools
• Reduction in unapproved AI usage

However, agencies should not judge success only by speed. A system that processes documents more quickly but produces unreliable classifications, exposes sensitive data or generates unauditable recommendations has not delivered real value.
The 90-day program should end with a renewal discipline. Every AI deployment needs a scheduled review point. At renewal, the agency should ask:

1. Is the use case still solving the original mission problem?
2. Are the outcome metrics meeting the threshold for continued investment?
3. Has the system’s data scope, user base or decision role changed?
4. Have model updates or vendor changes altered the risk profile?
5. Are security, privacy and operational controls still functioning?
6. Can the system be consolidated with another enterprise capability?
7. Is there an exit plan if the system no longer performs or no longer aligns with mission needs?

This is how agencies prevent pilots from becoming permanent but poorly understood fixtures in the environment.

---

Procurement Must Become a Continuous Governance Function​

Traditional technology procurement often assumes that the product being purchased will remain largely stable throughout the contract term. AI challenges that assumption.
Models can change. Features can be enabled by default. Providers can alter data retention terms, deployment architectures, subprocessor arrangements or safety controls. An AI system acquired as a simple assistant can be expanded into a workflow engine with access to agency systems.
That is why AI procurement cannot stop at award. It must include continuous vendor governance.

Contracting for transparency and change management​

Agencies should require enough information to assess the risk of AI products at the model, system and application level. The objective is not necessarily to demand proprietary model weights or sensitive trade secrets. It is to obtain the documentation necessary to make informed operational decisions.
A strong AI procurement package should address:

• The model or models used by the service
• The conditions under which models may be substituted or updated
• Data use, retention and deletion practices
• Hosting locations and authorization boundaries
• Subprocessors and supply-chain dependencies
• Security incident notification requirements
• Logging and audit capabilities
• Evaluation evidence and known limitations
• Support for accessibility, records and user feedback obligations
• Customer controls for disabling features or limiting data access
• Portability, export and termination rights

The agency should also ensure that the vendor’s responsibilities align with the agency’s own accountability. A contract can distribute operational tasks, but it cannot outsource public responsibility for mission decisions.

Avoiding the false choice between standardization and lock-in​

Central governance can produce a temptation to standardize on one platform for everything. That may simplify procurement in the short term, but it can create concentration risk, limit access to specialized capabilities and make future migration harder.
The better goal is standardized control planes, not forced uniformity. Agencies can support a managed portfolio of approved solutions while standardizing the controls around identity, data access, logging, evaluation, procurement and lifecycle management.
This approach allows agencies to use different tools where the mission requires them without treating every new deployment as a completely independent technology estate.

---

Security, Data and Human Oversight Are Not Add-Ons​

AI governance is sometimes described as a policy function separate from cybersecurity or data management. That separation is counterproductive. AI expands both the attack surface and the consequences of weak data practices.
A generative AI system may expose information through prompts, uploaded files, retrieval sources, output logs, connected tools or agent actions. It may also create a new pathway for prompt injection, data exfiltration, model manipulation or unintended automation.

Secure the entire AI system, not just the model​

Focusing only on the foundation model misses the broader system risk. A well-protected model can still be used unsafely if the surrounding application has weak access controls, excessive permissions, insecure integrations or insufficient logging.
Federal AI security should cover:

• Strong identity, authentication and least-privilege access
• Segmentation between sensitive data domains
• Secure API management
• Input and output monitoring appropriate to the use case
• Protection against prompt injection and malicious content
• Software supply-chain visibility
• Vulnerability management for AI applications and dependencies
• Event logging that supports incident response and audit
• Red-team testing for sensitive or externally exposed use cases
• Clear procedures for disabling or rolling back unsafe functionality

For agentic AI systems, the stakes rise further. An agent that can access systems, retrieve information, generate actions or initiate workflows needs carefully limited permissions and robust approval gates. The agency should treat autonomy as a graduated capability, not an all-or-nothing feature.

Data readiness determines whether AI can become useful​

AI will not compensate for poor data governance. If the underlying information is inconsistent, stale, incomplete, poorly labeled or inaccessible to authorized users, the system’s output will reflect those weaknesses.
Retrieval-augmented generation is a useful example. It can ground responses in agency-approved documents, but only if those documents are current, authoritative, properly permissioned and indexed with meaningful metadata. A retrieval system that mixes obsolete guidance with current policy can produce a confident but misleading answer.
Data stewardship for enterprise AI should establish:

• Authoritative sources for each mission domain
• Clear data owners and custodians
• Data quality expectations
• Metadata and lineage practices
• Permission-aware retrieval
• Retention and deletion rules
• Processes for correcting outdated or harmful content
• A method for separating experimentation data from production data

The core lesson is simple: AI is only as governable as the data and systems surrounding it.

---

Measuring Results Without Chasing Vanity Metrics​

AI programs often report the number of pilots launched, users provisioned or prompts submitted. These are adoption metrics, not necessarily outcome metrics.
An enterprise AI program should connect every significant use case to a mission measure. The measure will vary by agency and workflow, but it must answer whether the technology improved the work in a way that matters.
For example, a document-processing system might be assessed on:

• Time from intake to completed review
• Accuracy against established human review standards
• Rate of escalations or corrections
• Reduction in backlog
• Consistency across users and locations
• Impact on employee workload
• Cost per processed item

A knowledge assistant might be measured by:

• Search-to-answer time
• Answer grounding in approved sources
• User resolution rates
• Reduction in repetitive help desk tickets
• Frequency of incorrect or unsupported answers
• User trust and satisfaction
• Usage within approved boundaries

For high-impact AI, the performance bar should be higher. Agencies must be able to demonstrate that the system is performing reliably for its intended population and context, that meaningful human accountability remains in place and that there is a clear process for intervention when outputs fail.
This is where governance becomes a practical performance system. It creates the evidence needed to decide whether an AI capability should be expanded, modified, paused or retired.

---

The Strengths and Risks of a Governance-First Strategy​

The one-front-door model has substantial strengths. It gives leaders visibility over the AI portfolio, reduces duplicative spending, makes risk assessments more consistent and creates a natural route for reusing successful technical patterns. It also offers a better experience for program teams than forcing them to navigate multiple disconnected review bodies.
Most importantly, it reframes governance as a way to move faster with confidence. Teams know where to go, what information is required and which options are already approved. Leadership knows who owns each use case and whether investments are generating results.
But the model also carries risks if implemented poorly.

The risk of central bottlenecks​

A centralized intake system can turn into a gatekeeping mechanism that slows innovation. This happens when every proposal receives the same level of scrutiny, approvals lack service-level targets or the governance board focuses excessively on process over mission outcomes.
Agencies should counter this risk with automated routing, risk tiers, pre-approved patterns and published decision timelines. The front door must be easy to use and fast for low-risk work.

The risk of false assurance​

A completed form, approved architecture diagram or vendor checklist does not prove that an AI system is safe or effective. Governance can create false confidence if it becomes paperwork rather than ongoing oversight.
The remedy is continuous monitoring, measurable evaluations and renewal reviews. Governance must follow the system through its lifecycle, especially when models, data sources, integrations or user populations change.

The risk of over-standardization​

A drive to eliminate sprawl can lead to premature consolidation. Agencies may select a single platform before they fully understand their range of use cases. That can limit innovation, create vendor dependence and produce expensive workarounds for specialized missions.
The answer is to standardize common controls and reusable services while allowing justified variation in models and applications. Enterprise AI should be coherent, not monolithic.

---

Conclusion: Governance Is How Agencies Compound AI Value​

The defining challenge in federal AI is no longer whether agencies can build a compelling pilot. Many can. The challenge is whether they can turn early demonstrations into a durable capability that improves services, protects sensitive information, maintains public trust and uses resources responsibly.
A 90-day enterprise AI program is not a shortcut around hard modernization work. It is a disciplined beginning: one intake process, one portfolio view, risk-based governance, reusable delivery patterns, accountable mission ownership and measurable renewal decisions.
That framework addresses the real danger of unchecked AI adoption. Without it, agencies may accumulate tools, contracts and demonstrations while losing sight of outcomes. With it, they can make each successful use case strengthen the next—transforming AI from a source of organizational sprawl into a managed engine for mission results.

---

References​

1. Primary source: FedTech Magazine
   Published: 2026-07-24T13:57:01+00:00
   
   

   From Governance to Results: Building Enterprise AI in 90 Days

   Federal agencies can move from fragmented experiments to durable, compliant artificial intelligence without stalling on speed.

   fedtechmagazine.com