# AI Presentation Software for the Public Sector: Security and Procurement Checklist
> A procurement checklist for public sector buyers of AI presentation software: records requirements, accessibility, security classification, supplier risk, NIS2 and exit.
- Author: [Maximilian Betz](https://www.offgen.ai/en/authors/maximilian-betz)
- Published: 2026-08-26
- Updated: 2026-08-26
- Category: Regulated Industries
- Labels: Regulated Industries, Security & EU Regulation
- Canonical URL: https://www.offgen.ai/en/blog/ai-presentation-software-public-sector
> This article is for information only and does not constitute legal advice.
## Evidence for this article

This article supports its claims with 5 sources. Key sources include:

1. [Regulation (EU) 2016/679 (General Data Protection Regulation)](https://eur-lex.europa.eu/eli/reg/2016/679/oj?locale=en) (EUR-Lex)
2. [Directive 2014/24/EU on public procurement](https://eur-lex.europa.eu/eli/dir/2014/24/oj) (EUR-Lex)
3. [NIS2 implementation in Germany](https://www.bundesregierung.de/breg-de/bundesregierung/bundeskanzleramt/nis-2-richtlinie-deutschland-2373174) (German Federal Government)

[Full source list](#sources)
Public sector procurement of AI presentation software has to answer seven questions that private sector buyers can often skip: records and retention, accessibility, classification handling, the processing chain, supplier and concentration risk, transparency, and exit with usable formats.

Two of those, accessibility and records, are where I see the most expensive mistakes. Both are treated as compliance detail during evaluation and both turn into structural problems afterwards.

<Callout title="Scope and review">
  This is operational guidance, not legal advice. Procurement rules, records law, security classification frameworks and the scope of NIS2 implementation vary by member state and by entity. Your procurement, legal, security and accessibility functions must own the assessment.
</Callout>

## Accessibility is a procurement requirement, not a preference [#accessibility-is-a-procurement-requirement-not-a-preference]

Public bodies in the EU are subject to accessibility requirements for their digital content, and presentations that are distributed or published are frequently in scope.

This has a direct and often overlooked consequence for AI presentation tools. A tool that produces flattened images, rendered output or a proprietary viewer creates an accessibility failure at scale. Not one document at a time. Every document the tool produces, permanently.

What to require:

* Native text objects that assistive technology can read.
* A correct and controllable reading order.
* Alternative text support for images and charts, with a workflow that actually prompts for it.
* Charts as native objects rather than images, so data is available to assistive technology.
* Sufficient colour contrast, and information not conveyed by colour alone.
* Accessible tables with proper header structure.
* Export that preserves the accessibility structure rather than flattening it.

That last point catches many tools. Output can be accessible in the application and lose all structure on export, which is exactly when it reaches the public.

Ask for a demonstration with a screen reader during evaluation. Not a statement of conformance. A demonstration.

## Records requirements outlast the contract [#records-requirements-outlast-the-contract]

Records law generally applies to a document regardless of how it was produced. Retention schedules, archiving in a durable readable format, and the ability to produce a document in response to an information request.

Three implications for tool selection:

**Output format is a records question.** If your material only opens in the supplier's application, your retention obligation depends on that supplier continuing to exist and continuing to support the format. Retention periods in public administration routinely outlast software vendors.

**The working document may itself be a record.** Depending on your framework, drafts and internal working documents can fall within scope. Where a tool holds those in its own store, you need to know how they are retrieved.

**Information requests reach AI systems too.** If a request covers documents held by the authority, material inside a supplier's system may be in scope. You need a practical route to search and retrieve it.

Native, open document formats resolve most of this. It is one of the few places where a format decision made during procurement determines a compliance outcome decades later.

## Classification handling [#classification-handling]

Set the boundary explicitly before deployment and enforce it technically.

The policy question is not whether the tool is secure. It is which classification levels this specific tool, in this specific configuration, is approved to process. For higher classification levels the answer will often be none, and that is a legitimate outcome.

What matters is that the boundary is enforced rather than declared. A policy that relies on a user correctly assessing the classification of material at eight in the evening before a committee will fail, because it puts the control at the point of maximum pressure and minimum attention.

Practical requirements:

* Classification levels mapped to approved tools, published and easy to look up.
* Technical enforcement where possible, through workspace separation and content rules.
* Clear, memorable rules about what may never be entered regardless of tool.
* A fast route to get an answer for an unusual case, because slow answers drive workarounds.

## The processing chain [#the-processing-chain]

The same questions as any regulated procurement, with public sector emphasis.

<Checklist>
  * Where is data processed, for every component including retrieval, generation and rendering?
  * Which subprocessors are involved and where are they located?
  * Where do support engineers sit, and what can they access?
  * What is written to logs, telemetry and backups, and for how long?
  * If data leaves the EEA at any point, what mechanism applies and what assessment supports it?
  * Are inputs used for model training, contractually rather than as a policy statement?
  * Can retention be configured, and can deletion be demonstrated?
  * Does access follow existing organisational permissions and role structures?
</Checklist>

For German public sector buyers, the BSI IT-Grundschutz materials provide a structured basis for the security assessment, and where the entity falls within scope of national NIS2 implementation, supply chain security and risk management measures apply to ICT suppliers. Assess the applicable scope for your organisation and service rather than assuming it either applies or does not.

## Supplier and concentration risk [#supplier-and-concentration-risk]

Public bodies carry a continuity obligation that makes this more than a commercial question.

* Is the supplier financially stable and likely to persist for the contract term and beyond?
* What underlying infrastructure and model providers are in the chain, and do they appear elsewhere in your estate?
* If the supplier became unavailable, how would the function continue?
* Is the service genuinely substitutable, and how quickly?
* Are there sovereignty requirements that constrain the supplier or infrastructure choice?

The substitutability question again comes back to output format. A tool producing native, portable documents is substitutable. A tool holding your material in its own format is not, whatever the contract says about data return.

## Transparency and the EU AI Act [#transparency-and-the-eu-ai-act]

Public bodies frequently carry transparency obligations that private organisations do not, and citizens reasonably expect to know when AI was involved in material affecting them.

The AI Act position as of 2026:

* The AI literacy obligation under Article 4 has applied to deployers since 2 February 2025.
* Transparency obligations under Article 50 have applied since 2 August 2026.
* Annex III high risk obligations were deferred to 2 December 2027 by Regulation (EU) 2026/1744, in force since 27 July 2026.

Annex III includes several categories directly relevant to public administration, including certain uses in education, employment, access to essential public services, migration and law enforcement. A presentation assembly tool is normally not in those categories, but the assessment matters more here than in most sectors because the same platform may later be pointed at something that is.

Document the classification, define the permitted scope, and set a trigger to reassess if the scope expands.

## Running the procurement itself [#running-the-procurement-itself]

Public procurement rules constrain how you evaluate, not just what you buy. Two practical notes.

**Specify outcomes and standards rather than a product.** Requirements phrased around native output, accessibility conformance, processing locations, permission inheritance and exit format are defensible. Requirements that describe one supplier's feature set are not.

**Build the pilot into the process properly.** Ask for a demonstration against your own template, with a screen reader, using non sensitive material, including deliberate failure cases: a permission boundary, a request that cannot be satisfied, an attempt to alter protected content, an export check. A demonstration designed by the supplier tells you what they want you to see.

## The public sector checklist [#the-public-sector-checklist]

<Checklist>
  * Accessibility demonstrated with a screen reader, including after export.
  * Native output in a durable open format, verified against your records requirements.
  * Classification boundary defined and technically enforced.
  * Full processing chain documented, including support access and backup locations.
  * Training and retention positions written into the contract.
  * Access follows existing organisational permissions, tested through every surface.
  * Supply chain security assessed against the applicable framework for your entity.
  * Concentration and continuity risk assessed at estate level.
  * Exit plan with tested export format, timelines and deletion confirmation.
  * AI Act classification documented, with a reassessment trigger.
  * Transparency approach defined for material reaching citizens.
  * Requirements specified as outcomes and standards rather than as a product description.
</Checklist>

## Where offgen fits [#where-offgen-fits]

Two things matter most for this sector and both are structural rather than featural.

Output is native PowerPoint, which addresses the records and accessibility questions at the same time. Text is real text, charts are real charts with data, reading order and alternative text are available, and the file opens without our application. That is a durable answer to the retention obligation and to the exit question.

Retrieval runs inside existing organisational permissions rather than a separate model, and protected content stays protected through [lockable elements](/en/product/lockable-elements).

Our [security overview](/en/security), [trust center](/en/security/trust-center) and [data processing agreement](/en/data-processing-agreement) provide the documentation for the assessment above.

The decision I would treat as most consequential: the output format. It looks like a technical detail during evaluation and it determines accessibility, records compliance and exit cost for as long as the documents exist, which in public administration is a very long time.
## Frequently asked questions

### What should public sector buyers check in AI presentation software?

Seven areas: records and retention requirements, accessibility, security classification handling, the full processing chain including support access, supplier and concentration risk, transparency to citizens where relevant, and exit with usable data formats. Procurement rules also constrain how you run the evaluation itself.

### Why does accessibility matter more in public sector presentations?

Public bodies in the EU are subject to accessibility requirements for their digital content, and presentations distributed or published are frequently in scope. A tool that produces flattened images with no reading order, no alt text and no selectable text creates an accessibility problem at scale rather than one document at a time.

### Can public bodies use AI tools with classified or restricted material?

Only where the tool has been assessed and approved for that classification level, which for higher levels usually means it cannot be. Set the classification boundary explicitly before deployment and enforce it technically, because a policy that relies on users self assessing at the point of use will fail.

### How does NIS2 affect AI presentation software procurement?

Where the entity falls within scope of national NIS2 implementation, supply chain security and risk management measures apply to ICT suppliers. A presentation tool processing official information is part of that supply chain. Assess the applicable scope for your organisation and service rather than assuming.

### What records requirements apply to AI generated documents?

Records law generally applies to the document regardless of how it was produced. That means retention schedules, archiving in a durable and readable format, and often the ability to produce the document in response to an information request. Proprietary output formats create a records problem, not just a portability one.

### What is the most overlooked question in public sector AI procurement?

Exit combined with format. Contracts end, suppliers change and procurement cycles repeat. If your material only opens in the supplier's application, you have created a lock in that a future procurement will have to pay for, and records obligations may outlast the contract by decades.
## Sources

1. [Regulation (EU) 2016/679 (General Data Protection Regulation)](https://eur-lex.europa.eu/eli/reg/2016/679/oj?locale=en) — EUR-Lex, 2016-04-27; accessed 2026-08-26.
2. [Directive 2014/24/EU on public procurement](https://eur-lex.europa.eu/eli/dir/2014/24/oj) — EUR-Lex, 2014-02-26; accessed 2026-08-26.
3. [NIS2 implementation in Germany](https://www.bundesregierung.de/breg-de/bundesregierung/bundeskanzleramt/nis-2-richtlinie-deutschland-2373174) — German Federal Government; accessed 2026-08-26.
4. [IT-Grundschutz Compendium](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Grundschutz/International/bsi_it_gs_comp_2021.pdf?__blob=publicationFile&v=4) — German Federal Office for Information Security (BSI); accessed 2026-08-26.
5. [Trust Center](https://www.offgen.ai/en/security/trust-center) — offgen; accessed 2026-08-26.
## Related articles

- [Enterprise AI Presentation Software: Evaluation Checklist for 2026](https://www.offgen.ai/en/blog/enterprise-ai-presentation-software-checklist)
- [AI Presentation Governance: A Practical Framework for Enterprise Teams](https://www.offgen.ai/en/blog/ai-presentation-governance-framework)
- [Editable AI PowerPoint: Why Native Slides Matter for Professional Teams](https://www.offgen.ai/en/blog/editable-ai-powerpoint-native-slides)
