AI and FedRAMP: Authorising AI Services for Government

Adding AI to a FedRAMP authorised service turns almost entirely on one decision: where the model runs relative to the authorisation boundary. Everything else follows from it. This guide covers that decision and where programmes stall, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

What does the boundary decision determine?

Architecture, timeline, and whether the programme is feasible at all.

Arrangement	Consequence
Model runs inside the boundary	Assessed as a component; feasible
External provider with authorisation	Dependency documented; workable
External provider without authorisation	Blocking; agency data cannot flow
Self-hosted open weights	Inside boundary; operational burden
Model updates	Change control question each time
Output logging	In-boundary data with retention duties

Why is the external provider question so hard?

Because prompts carry agency data. A design that calls an external model service is transmitting that data outside the boundary, which is exactly what the authorisation exists to control.

The workable paths are an authorised provider, a model deployed inside the boundary, or a design where no controlled data reaches the model — and the third is narrower than teams hope. Establish this before architecture rather than during assessment.

How does continuous monitoring apply?

AI components are monitored like any other: vulnerability scanning, configuration management, incident reporting, and change control, on the same cadence.

The additional question is whether output quality degradation counts as a reportable event. It is not a security incident in the traditional sense and it can materially affect an agency's use of the service, which makes it worth defining a position rather than discovering one during an incident.

Do model updates count as significant changes?

They can. A model update that materially changes behaviour raises the significant change question, and providers need a documented position on which updates fall within the existing authorisation.

That has product consequences: a service that silently adopts each new model version has a change control problem, while one that pins versions and updates deliberately has a manageable one. Pin and update deliberately. See what is a regression suite for ai.

What evidence do you need?

Boundary documentation showing where the model runs, authorisation evidence for any external dependency, continuous monitoring covering AI components, change control records for model updates, and a documented position on what counts as a significant change.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes model hosting and version pinning into the architecture from day one. A service that cannot state which model version served which request cannot answer change control questions.

It also makes self-hosting more attractive than it would otherwise be, because it keeps the boundary clean at the cost of operational burden. That trade is worth making deliberately rather than discovering during assessment.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Designing around an external provider before checking its authorisation status. Adopting model updates automatically. Treating output quality as outside monitoring. And failing to record which model version served which request.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

What about agencies deploying rather than providing?

They inherit the authorisation of the services they use and carry their own responsibilities around how the system is operated, including oversight of decisions affecting people and record-keeping.

Suppliers should expect those questions from agency customers regardless of the authorisation status, and having the answers ready shortens procurement considerably.

What should you do first?

Decide where the model will run relative to the boundary, and confirm the authorisation status of any external dependency. Do this before any architecture work, because it can invalidate a design entirely.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: model hosting and the authorisation boundary decided before architecture, model versions pinned and recorded per request so change control is answerable, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read what is an air-gapped AI deployment.