Deploying a high-risk AI system safely — the deployer's playbook

What deployers actually have to do

From Article 26, plus the specific obligation flows:

• Use the system according to the provider's instructions for use (IFU).
• Assign human oversight to a named person who understands the system.
• Retain logs the system generates (minimum six months, longer if the provider specifies).
• Monitor performance and report incidents to the provider.
• Inform affected individuals when the system significantly influences a decision about them.
• For specific categories (public bodies, credit/insurance AI): run a FRIA before deployment.

What this looks like as an operational rhythm:

Before deployment

1. Classify the system in Klarvo. Confirms Annex III sub-category and the obligations.
2. Name the human-oversight owner. A specific person, not a role. They must understand the system's capabilities and limits, and have authority to override or pause.
3. Capture the IFU and conformity-assessment summary from the vendor. Upload to the evidence vault. If the vendor can't provide both, escalate — that's their AI Act problem leaking into yours.
4. If a FRIA is required (public body, credit/insurance), run it. See the FRIA guide.
5. Draft the affected-individuals notice and route it through legal review. Klarvo can pre-fill from the classification.

Day-to-day operations

1. Use the system as the IFU prescribes. No off-label use. If you want a new use case, treat it as a new system — re-classify, re-document.
2. Log retention is automatic if you configure it. Capture the system's logs to your existing storage; ensure retention meets the provider's minimum and your own audit needs.
3. Human oversight is real, not theatre. The named owner reviews the system's decisions on a defined cadence — daily for high-volume, weekly for low-volume. Document the cadence and what's reviewed.

Weekly / monthly rituals

Performance monitoring

Define outcome metrics before deployment (acceptance rates, drift indicators, complaint rates by segment). Review weekly during the first month, monthly thereafter. Document the review — date, who attended, what was reviewed, decisions taken.

Incident handling

Define what counts as an incident (e.g. an outlier outcome, a complaint, a model drift signal beyond threshold). Define the escalation path. When incidents happen, log them in Klarvo with the affected systems, root cause, mitigation, and the report to the provider.

Quarterly cycle

1. Review of the human-oversight log — was oversight actually performed on cadence?
2. Vendor refresh — has the provider updated the IFU? Are there new known issues? Has the conformity assessment changed?
3. Affected-individuals notice review — is the wording still accurate for what the system actually does?
4. FRIA refresh — substantial modifications or material changes in context trigger a FRIA update.

What the auditor / regulator will ask for

• The classification memo for the system, with article reference and date.
• The IFU and conformity-assessment summary from the provider.
• The named human-oversight owner, the oversight log, and evidence the cadence was followed.
• The system's operational logs for the retention period.
• Incident log + reports to the provider.
• The FRIA, if required, with the named sign-off and review schedule.
• Any change-log of substantial modifications.

Klarvo's evidence pack export bundles all of the above into a single document — the audit is then a presentation, not a scramble.