Back to Use Cases

AI Governance & Regulatory Compliance

Challenge

Organisations deploying AI systems face increasing governance and regulatory pressure. Regulations and standards such as the EU AI Act, GDPR, HIPAA, PCI-DSS, and SOX require organisations to demonstrate what systems do, how decisions are made, what safeguards exist, and how decisions can be audited.

In many organisations this information is scattered across Word documents, PowerPoint slides, wiki pages, spreadsheets, architecture diagrams, ticket systems, and tribal knowledge. The result is documentation drift.

The architecture says one thing, the implementation does another, and the audit trail is reconstructed manually after the fact. The challenge is not only producing documentation. The challenge is keeping governance aligned with the system as it evolves.

How DCL Helps

DCL brings governance into the capability model. Capabilities explicitly declare the business responsibility being performed, the actor initiating or participating in the capability, the accepted input, the possible outcomes, the rules that constrain decisions, the effects caused by the capability, the policies attached to the capability or its effects, and the events or audit evidence that should be emitted.

Because these declarations are part of the language, they can be checked by the compiler and projected into generated documentation, diagrams, summaries, and reports.

DCL does not replace legal review or compliance tooling. Instead, it provides a compiler-verifiable architectural source from which governance artefacts can be generated and checked.

Example

This example models an AI-assisted job applicant screening capability using valid DCL 1.0 syntax. It keeps the governance model explicit without claiming that the compiler performs legal or operational compliance work on its own.

language dcl 1.0

actor Applicant is human
actor Recruiter is human
actor ScreeningAssistant is agent

shape JobApplication {
  applicantId: Uuid required
  roleId: Uuid required
  resumeText: Text required
  consentGiven: Boolean required
  applicationComplete: Boolean required
  meetsRoleCriteria: Boolean required
}

shape ScreeningDecision {
  applicantId: Uuid required
  roleId: Uuid required
  decision: Text required
  reason: Text required
}

effect RecordScreeningDecision is persistence
effect NotifyApplicant is notification
effect LogScreeningAuditEvidence is persistence

event ApplicantScreeningRecorded is ScreeningDecision
event ApplicantNotificationSent is {
  applicantId: Uuid required
  decision: Text required
}

policy ScreeningDataProtection {
  data_protection {
    sensitivity personal
    minimization required
    masking required
  }
}

policy ScreeningGovernanceEvidence {
  governance {
    audit required
    evidence required
  }
}

policy MinimumScreeningConfidence {
  confidence {
    threshold 0.82
  }
}

policy HumanOversightRequired {
  governance {
    audit required
    evidence required
  }
}

capability ScreenJobApplication {
  intent JobApplication from ScreeningAssistant

  actors {
    applicant: Applicant
    recruiter: Recruiter
    assistant: ScreeningAssistant
  }

  outcomes {
    InviteToInterview is ScreeningDecision
    Reject is ScreeningDecision
    PendingHumanReview is ScreeningDecision
  }

  rules {
    ConsentRequired:
      input.consentGiven is true

    ApplicationComplete:
      input.applicationComplete is true

    MinimumEligibilityMet:
      input.meetsRoleCriteria is true
  }

  effects {
    RecordScreeningDecision
    NotifyApplicant after RecordScreeningDecision
    LogScreeningAuditEvidence after RecordScreeningDecision
  }

  events {
    emits ApplicantScreeningRecorded
    emits ApplicantNotificationSent
  }

  policies {
    ScreeningDataProtection governs capability
    ScreeningGovernanceEvidence governs effect LogScreeningAuditEvidence
    MinimumScreeningConfidence governs outcome InviteToInterview
    HumanOversightRequired governs outcome PendingHumanReview
  }

  observe {
    capability duration as screening_duration
    outcome PendingHumanReview count as screening_human_review_required
    effect LogScreeningAuditEvidence count failures as screening_audit_logging_failures
    event ApplicantScreeningRecorded count as screening_decisions_recorded
  }

  when {
    ConsentRequired violated then PendingHumanReview
    ApplicationComplete violated then PendingHumanReview
    MinimumEligibilityMet violated then Reject
    RecordScreeningDecision failed then PendingHumanReview
    policy MinimumScreeningConfidence fails then PendingHumanReview
    otherwise then InviteToInterview
  }
}

Open in Playground

The example demonstrates that the capability is explicit, possible outcomes are finite, governance policies are attached in source, effects and audit evidence are declared, and documentation or reports can be generated from the same validated source.

Benefits

Single Source of Truth

DCL keeps capability behaviour, governance policies, and generated documentation connected to the same source.

Compiler-Checked Architecture

The compiler can detect missing references, invalid attachments, incomplete definitions, and unsupported constructs before the model is used downstream.

Reduced Documentation Drift

Documentation, diagrams, and summaries can be generated from the validated DCL model rather than maintained separately.

Improved Audit Readiness

Capabilities, actors, outcomes, effects, policies, and events are declared explicitly, making it easier to explain what the system is responsible for.

AI-Ready Governance

For AI-enabled systems, DCL provides a stable capability contract even when implementation details such as models, prompts, and runtime tools evolve.

Looking Forward

AI governance is only one use case. The same pattern applies wherever organisations need to describe what systems are responsible for, what rules and policies apply, what outcomes are possible, and what evidence must be produced.

DCL provides a way to move from static documentation toward compiler-verifiable architecture.