Skip to main content
Connic
Platform

AI Governance

AI Governance is Connic's Enterprise documentation workspace for EU AI Act readiness. Register AI systems, record preliminary provider and deployer assessments, generate controls, document customer-managed Article 50 disclosures, track incidents, and export immutable, metadata-only evidence for auditors and counsel.

Last updated

Summary

AI Governance sits alongside your agents, runs, and deployments. It turns the answers you record about scope, operator role, and risk into a versioned readiness record: a preliminary classification, a mapped set of obligations, and an audit-ready evidence trail. It is a documentation and evidence workflow, not a legal determination. Deadlines, authority sufficiency, and final classification remain confirmed by you and your counsel.

At a glance
  • For decision-makers: a single, exportable record of which EU AI Act obligations your AI systems trigger, how far each control has progressed, and what evidence backs it, scoped to the environments and agents you select.
  • For implementers: project-scoped API routes and dashboard pages to register systems, run assessments, generate and work controls, document Article 50 policies and attestations, log incidents, and stream hash-verified evidence archives.

Access and Permissions

AI Governance is an Enterprise entitlement. Requests to the compliance routes return 403 unless the project is on an Enterprise plan. Access within an entitled project is gated by four project permissions:

Permissions
compliance.viewRead the overview, AI systems, assessments, controls, transparency policies and applications, monitoring plans, incidents, and evidence snapshots.
compliance.manageCreate and update AI systems, record and review assessments, generate and update controls, configure transparency policies, record attested applications, and maintain monitoring plans.
compliance.exportCapture evidence snapshots and download the streamed evidence archive.
compliance.incidents.manageCreate and update AI incident records, including reporting deadlines and authority-notification evidence.

Every mutation is written to the project audit log with the actor, action, and before and after state.

AI Systems and Lifecycle

An AI system is a project-scoped record of a use case, independent of any single agent. You describe its intended purpose, owner, geographies, and affected persons, and link it to the environments, deployments, and agents that implement it. Those links scope the telemetry, disclosure evidence, and incident references that attach to the system.

System states
draftBeing described. A pristine draft with no governance records is the only state that can be deleted.
activeCurrently in use.
retiredNo longer in use. Retire a system instead of deleting it once it has any assessments, controls, incidents, policies, or snapshots, so the change history is preserved.

Preliminary Assessments

An assessment is an immutable, versioned answer set covering EU scope, operator roles, prohibited-practice screening, high-risk routes (Annex I and Annex III, including profiling and the Article 6(3) derogation), and the Article 50 transparency dimensions. Connic derives a deterministic result from those answers using a pinned catalog version and records the regulatory source it was reviewed against. The result is always labelled preliminary and is explicitly not a legal determination.

Assessments are never edited in place. Recording new answers creates a new version, and only the latest version can be approved. Approval requires a nonblank rationale, at least one supported operator role, and explicit acknowledgment when any answer was left uncertain.

Operator-role coverage

Connic supports the provider and deployer roles end to end. Other roles are recognized so you do not lose the factual record, but their obligations are out of scope for control generation:

  • Authorised representative (Article 22)
  • Distributor (Articles 24 and 25)
  • Importer (Articles 23 and 25)
  • Product manufacturer (Article 25(3))

If an assessment includes an unsupported role, assessment approval, control generation, control refresh, and evidence export are blocked until the coverage is resolved. At least one supported role is required to proceed. The assessment remains a preliminary record either way.

Controls

Controls are generated from the latest approved assessment only. Connic maps each applicable obligation to an operational control, with the governing article, an applicability rationale, and an implementation type that says who is accountable:

  • connic: the platform provides the mechanism (for example traceability and logging).
  • customer: your organization owns the obligation.
  • shared: platform features support an obligation you still own.
  • external: handled outside the platform (for example notified-body conformity and EU database registration).

Each control carries a status (gap, needs_evidence, configured, or not_applicable) and an evidence status, and links to the Connic features that support it, such as runs and traces, logs, approvals, and judges. Refreshing re-derives the set against the current latest approved assessment while retaining the change history. Marking a control not_applicable requires an exception rationale.

Article 50 Transparency Documentation

Each system can hold one transparency policy documenting how your organization handles Article 50 disclosures, including direct interaction, synthetic-content marking, deepfakes, biometric and emotion use, and public-interest text. The policy records copy, locales, placement, frequency, display mode, customer implementation, and supporting verification.

Connic stores the policy and supporting evidence only. It does not modify prompts, responses, streams, or connector traffic; inject prefixes, banners, or metadata; or watermark media. Your organization is responsible for implementing and delivering every disclosure or marking in its application, with upstream-provider evidence recorded where relevant.

Disclosure Evidence and Attestation Provenance

Transparency applications document that a disclosure or marking was applied, failed, or could not be confirmed. Each record uses customer_attestation or upstream_attestationprovenance and requires the attesting party, timestamp, evidence reference, and factual basis. Provider evidence supports the customer record; it does not transfer the customer's responsibility.

Evidence lifecycle
appliedYour attestation records that delivery was confirmed. Both the applied and finalized timestamps are set and no failure reason is present.
failed / delivery_unknownDelivery did not complete or could not be confirmed. The record is finalized with a required failure reason.

Records are idempotent: a repeated request with the same idempotency key and content returns the existing record, while a conflicting reuse is rejected. Attestations may document any customer-managed surface, including WebSocket applications.

Attested synthetic-content application (request body)
{
  "disclosure_type": "synthetic_content",
  "status": "applied",
  "provenance": {
    "source": "upstream_attestation",
    "attested_by": "Model Provider Trust & Safety",
    "attested_at": "2026-07-15T09:30:00Z",
    "evidence_reference": "https://provider.example/c2pa/attestation/8f21",
    "basis": "Provider marks generated media with C2PA content credentials."
  },
  "application_metadata": {
    "marking_method": "c2pa"
  }
}

Monitoring and Incidents

Each system can hold a monitoring plan with an owner, review cadence, signals, thresholds, and a next-review date. An active plan requires an owner, a next-review date, and either signals or a documented monitoring procedure. Plans surface on the overview when a review is due.

Incidents record awareness time, severity, causal-link and reportability status, corrective actions, and notification history, and can reference the run, environment, or deployment involved. Marking an incident reported or closed requires recorded authority-notification evidence with a timestamp, recipient or authority, channel, and external reference.

Connic records the reporting deadline, its stated basis, and the notification evidence. It does not calculate deadlines or determine whether a notification is legally sufficient. Deadlines and authority sufficiency remain confirmed by you and your counsel.

Evidence Snapshots and Exports

An evidence snapshot is an immutable, metadata-only capture of the current governance state for the systems and environments you select, over an optional time window. Snapshots are content-addressed with a SHA-256 hash over a canonical serialization, cannot be edited or deleted, and persist for the lifetime of the project. They deliberately exclude raw prompts and model outputs.

A snapshot bundles the systems, their latest assessments, controls, transparency policies and applications, monitoring plans, and incidents. It also includes telemetry for runs, approvals, and judges scoped to the selected system, agent, and environment pairs. Audit events are project-scoped and cannot be attributed exactly to an environment. An environment-scoped export therefore marks audit-event telemetry as unavailable, with the reason recorded in explicit telemetry scope metadata, instead of substituting a project-wide count. An export without an environment filter can include the project-scoped audit-event count. Coverage metadata records the environment and time scope, the plan data-retention window, and any missing evidence.

Snapshot quota defaults and plan configuration

Snapshot count and byte quotas are operational plan option. If a plan omits a setting, Connic applies these conservative defaults:

  • 100 snapshots per project
  • 10 MiB per snapshot
  • 100 MiB of snapshot storage per project

Downloading an export streams a ZIP archive containing a human-readable report, a canonical JSON payload, per-collection CSV and JSON files, and a manifest with per-file SHA-256 integrity hashes. The response carries the snapshot content hash and the archive hash as headers so recipients can verify the download independently. These checksums detect whether content differs from the recorded hashes. They are not cryptographic signatures, do not identify a signer or establish publisher authenticity, and do not certify the archive or its legal sufficiency.

Create evidence snapshot (request body)
{
  "name": "Q3 board review",
  "system_id": "b4c3d2e1-...",
  "environment_ids": ["f9e8d7c6-..."],
  "time_from": "2026-04-01T00:00:00Z",
  "time_to": "2026-06-30T23:59:59Z"
}

API and Workflow

Everything in AI Governance is available through the project-scoped REST API under /v1/projects/{project_id}/compliance. The main route families are:

  • /overview: aggregate readiness across systems, controls, transparency, incidents, and monitoring.
  • /systems and /systems/{id}: manage AI systems and their links.
  • /systems/{id}/assessments and .../review: record and approve preliminary assessments.
  • /controls, /systems/{id}/controls/generate, and .../refresh: generate and maintain controls.
  • /systems/{id}/transparency-policy and .../transparency-applications: configure Article 50 policy and record evidence.
  • /systems/{id}/monitoring-plan: maintain the monitoring plan.
  • /incidents and /incidents/{id}: manage incident records.
  • /evidence-snapshots and /evidence-snapshots/{id}/download: capture and export evidence.
1

Register the AI system

Describe the use case and link it to the environments, deployments, and agents that implement it.

2

Record a preliminary assessment

Capture EU scope, operator roles, risk routes, and Article 50 dimensions. Connic derives the preliminary result.

3

Approve the latest version

Provide a rationale, confirm supported role coverage, and acknowledge any uncertain answers.

4

Generate and work controls

Produce controls from the approved assessment and drive each toward configured with linked evidence.

5

Document the transparency implementation

Record the Article 50 policy your application implements, then add customer or upstream attestations as evidence.

6

Monitor and record incidents

Keep the monitoring plan current and log incidents with confirmed deadlines and authority-notification evidence.

7

Snapshot and export

Capture an immutable snapshot and stream the hash-verified evidence archive for auditors and counsel.

Open AI Governance API

Legal Boundaries

AI Governance produces readiness records and evidence. It does not provide legal advice, make legal determinations, issue certifications, or substitute for professional counsel. Assessment results are preliminary. Final classification, reporting deadlines, and the sufficiency of any authority notification remain your responsibility, confirmed with your own legal counsel.

Obligation mappings reference Regulation (EU) 2024/1689 (the EU AI Act) by article. Use the official text as the primary source. Article references in Connic point to obligations to review, not conclusions Connic has reached on your behalf.

Common Questions

Does an approved assessment mean my system is compliant?

No. An approved assessment is a preliminary, documented readiness record, not a legal determination or certification of compliance.

Which operator roles does Connic support?

Provider and deployer are supported end to end. Authorised representative, distributor, importer, and product manufacturer are recorded for history but block approval, control generation, and export until resolved.

Do evidence snapshots contain prompts or model outputs?

No. Snapshots are metadata-only. They exclude raw prompts and outputs and include structured records plus telemetry for runs, approvals, and judges. Audit-event telemetry is project-scoped when available; an environment-scoped export marks it unavailable and records why in its scope metadata.

Does Connic calculate incident reporting deadlines?

No. Connic records the deadline you enter, its stated basis, and your authority-notification evidence, but does not calculate deadlines or judge legal sufficiency.

Does Connic deliver Article 50 disclosures?

No. Connic documents your policy and evidence. Your organization implements and delivers disclosures and markings; upstream-provider evidence can support that record without transferring responsibility.