US AI in the Public Sector – What Applies?
There's no general ban – Swedish government agencies already use US cloud services. But the decision must rest on a documented risk assessment: where storage and inference happen, which transfer mechanism applies, and what happens if a US government request lands. For high-risk systems under the AI Act, a fundamental rights impact assessment is also required before deployment.
Swedish government agencies are caught in a bind: citizens expect world-class digital service, the strongest AI models come from US vendors – and government is subject to rules that set a higher bar than most private organizations face. The question isn’t whether US AI may be used. The question is what it takes for a yes to hold up under audit.
The testimony that frames the risk
The most-cited episode in the debate came from France. During a hearing before the French Senate, a representative of Microsoft France confirmed, under oath, that the company can’t guarantee European customers’ data is protected against US government requests. The same testimony noted that such a request against their European public-sector customers had never occurred.
That’s exactly the risk picture an agency has to weigh openly: the probability looks low, the consequence can be high, and there are no guarantees. A risk assessment that pretends any of those three elements doesn’t exist – in either direction – won’t hold up to internal governance or external audit. Write both halves of the testimony into the decision record and weigh them against the sensitivity of the data.
The public sector carries extra obligations
Beyond GDPR’s requirements for lawful processing and documented third-country transfers, public bodies carry obligations that private companies don’t.
- FRIA before deployment. Article 27 of the AI Act requires public bodies to carry out a fundamental rights impact assessment before a high-risk system goes into operation. It has to be in place before the system meets citizens – not afterward.
- Public access and traceability. Decisions on vendor choice and risk acceptance are public records. Assume every assessment will be read by journalists, auditors, and regulators.
- The signal from the EU level. The EU’s own institutions have had their cloud agreements with US vendors reviewed and been forced to tighten terms and configurations. That review is a useful benchmark: if your setup falls below that bar, you need good reasons.
The documentable path to a yes
Agencies that have landed on a sustainable yes tend to build the decision on four concrete components:
| Component | What it means |
|---|---|
| EU inference as active configuration | Data processing happens in the EU through an active, verified configuration choice – not an assumption about default settings |
| Customer-controlled keys | Encryption where the agency controls the keys is used wherever the service offers it, and the limitation during inference is documented honestly |
| Complete subprocessor map | All subprocessors and their roles are mapped, with monitoring of changes and the right to object |
| Non-US fallback path | A designated alternative for the most sensitive workflows that can be activated if the legal situation or terms change |
A scenario that shows the logic: a municipality wants to introduce an AI assistant for citizen services. It starts with workflows built on open information – fees, opening hours, application processes – where no sensitive personal data is processed. In parallel, the configuration for EU processing is documented, the subprocessor map is drawn up, and a European fallback path is identified for the next stage, where case data may become relevant. Every step has its own decision record. When the regulator asks, the answers are on paper.
At Weapp we help organizations build AI solutions where configuration, logging, and vendor choice can be produced on demand – that’s usually the difference between a yes that holds and a yes that gets overturned.
The legal landscape keeps moving – date the decision
The transfer mechanisms between the EU and the US have been struck down twice by the Court of Justice of the EU, and the current arrangement is being challenged in court on an ongoing basis. That doesn’t mean decisions should be postponed while waiting for final clarity – it isn’t coming. It means every decision should be dated, built on named legal sources and vendor statements, and have a designated owner who monitors changes.
In practice: build an annual reassessment into your operational planning, subscribe to regulators’ updates, and write the fallback path concretely enough that it can be activated without a fresh year of investigation. An agency that can show when, on what grounds, and with what readiness the decision was made stands firm even as the world changes. Get in touch if you’d like support structuring the record.
Frequently asked questions
Is there a ban on US AI services in the public sector?
No. There's no general ban, and US cloud services are already used widely across Swedish government. Responsibility sits with each agency: processing must be lawful, risks analyzed and documented, and sensitive data may require special safeguards or a different path.
What did Microsoft say in the French Senate?
A representative of Microsoft France confirmed under oath that the company can't guarantee data is protected against US government requests – while, per the same testimony, such a request against their European public-sector customers had never occurred. Both parts belong in an honest risk assessment.
What is a FRIA and when is it required?
A FRIA is a fundamental rights impact assessment under Article 27 of the AI Act. Public bodies must carry it out before a high-risk system goes into operation. It complements GDPR's impact assessment and focuses on how the system can affect individuals' rights.
Is it enough that data is stored in an EU data center?
No, not by itself. US vendors can be subject to US legislation like the CLOUD Act regardless of where the data center is located. Storage in the EU is an important component, but it has to be combined with an analysis of legal access, customer-controlled keys where possible, and a documented transfer assessment.
What is meant by a non-US fallback path?
It means the agency identifies an alternative – a European vendor or its own operating environment – to which the most sensitive workflows can move if the legal situation or terms change. The fallback path doesn't need to be functionally equivalent, but it should be identified, tested at small scale, and ready to activate.