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.
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.
- 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:
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.
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.
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.
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.
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.
{
"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.
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 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.
{
"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./systemsand/systems/{id}: manage AI systems and their links./systems/{id}/assessmentsand.../review: record and approve preliminary assessments./controls,/systems/{id}/controls/generate, and.../refresh: generate and maintain controls./systems/{id}/transparency-policyand.../transparency-applications: configure Article 50 policy and record evidence./systems/{id}/monitoring-plan: maintain the monitoring plan./incidentsand/incidents/{id}: manage incident records./evidence-snapshotsand/evidence-snapshots/{id}/download: capture and export evidence.
Register the AI system
Describe the use case and link it to the environments, deployments, and agents that implement it.
Record a preliminary assessment
Capture EU scope, operator roles, risk routes, and Article 50 dimensions. Connic derives the preliminary result.
Approve the latest version
Provide a rationale, confirm supported role coverage, and acknowledge any uncertain answers.
Generate and work controls
Produce controls from the approved assessment and drive each toward configured with linked evidence.
Document the transparency implementation
Record the Article 50 policy your application implements, then add customer or upstream attestations as evidence.
Monitor and record incidents
Keep the monitoring plan current and log incidents with confirmed deadlines and authority-notification evidence.
Snapshot and export
Capture an immutable snapshot and stream the hash-verified evidence archive for auditors and counsel.
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.