AI Presentation Software for the Public Sector: Security and Procurement Checklist

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.

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 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

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 same questions as any regulated procurement, with public sector emphasis.

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

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

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

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

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.

Our security overview, trust center and 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.