Trust, Safety & Governance
How we scope evidence, controls, testing, and accountability for AI systems, without turning framework alignment into a certification claim.
Our principles
Three commitments that guide how we propose, scope, and evaluate controls.
Safety by default
Our design standard is to identify material failure modes, human accountability, and operating boundaries before increasing autonomy. The controls are then scoped and verified for the specific deployment.
Transparency over black boxes
We favour inspectable evidence such as source references, decision records, version history, and escalation reasons. The appropriate record depends on the workflow, data, risk, and systems involved.
Requirements before claims
We map applicable requirements and use recognised frameworks to inform control design. Framework alignment supports compliance work; it is not certification, legal advice, or a guarantee of compliance.
Control patterns we can scope
The appropriate controls depend on the workflow, data, risk, client environment, and agreed scope. This is a design menu, not a claim that every control exists in every deployment.
Data Handling & Privacy
- Data inventory and minimisation requirements agreed for the workflow
- Storage and transit encryption requirements verified against the deployed stack
- Role-based access, secrets handling, and event logging scoped to risk
- Retention and deletion behaviour documented and acceptance-tested
- Data Processing Agreements used where the parties, processing, and applicable law require them
- Model-provider data-use and retention terms recorded before client data is connected
Model Selection & Governance
- Provider evaluation across capability, reliability, data terms, cost, and lock-in
- Approved access path and account tier documented for the deployment
- Model, prompt, tool, policy, and threshold versions recorded
- Evaluation against a frozen, workflow-specific baseline
- Portability and provider concentration assessed when material
Testing & Red-Teaming
- Acceptance and regression suites sized to the workflow and risk
- Threat-informed tests for prompt injection, data extraction, and unsafe tool use where applicable
- Impact and bias evaluation where people or protected characteristics may be affected
- Known exceptions and adversarial cases retained in the evaluation set
- Coverage, exclusions, and unresolved risks reported with results
Monitoring & Observability
- Workflow-specific quality, latency, error, and escalation measures
- Alerts tied to declared thresholds and an accountable owner
- Privacy-aware records sufficient to reconstruct material decisions
- Variable-cost tracking where spend is operationally material
- Change and regression checks for models, prompts, inputs, policies, and integrations
Incident Response
- Named escalation and decision paths for relevant AI failure modes
- Rollback, pause, or bounded fallback designed and tested where feasible
- Post-incident evidence, cause, and remediation recorded
- Notification responsibilities and timelines agreed for the engagement
Framework alignment, not certification
These sources can inform requirements, control design, testing, and evidence. Applicability must be assessed for the specific organisation and use case.
EU AI Act
We can support system inventory, role and risk classification, technical documentation, evaluation, and human-oversight design. Applicable duties and conformity decisions remain a matter for the responsible organisation and qualified advisers.
GDPR
We can support data mapping, minimisation, retention, access control, processor review, DPA inputs, and DPIA evidence where applicable. These controls contribute to a client's compliance programme but do not by themselves establish GDPR compliance.
SOC 2 Type II
The Trust Services Criteria can inform control mapping and evidence design for systems in scope. Clarvia does not claim a SOC 2 Type II report or imply that framework-informed work makes a client environment attested.
HIPAA
For US healthcare use cases, architecture and delivery can be scoped around the client's privacy, security, access, audit, vendor, and agreement requirements. Clarvia does not claim HIPAA certification or guarantee that a deployment is compliant.
OWASP LLM Top 10
The current OWASP guidance can inform a threat model and test plan for relevant LLM risks. Test coverage and exclusions should be documented; using the list does not prove that a system is free of vulnerabilities.
NIST AI RMF
Govern, Map, Measure, and Manage can structure risk ownership, evaluation, and monitoring artifacts. Referencing NIST AI RMF is not certification and does not replace organisation-specific risk decisions.
ISO 27001
ISO 27001 controls can inform access, incident, asset, and supplier-security work when they are in scope. Clarvia does not claim ISO 27001 certification, and project-level control alignment is not equivalent to an audited ISMS.
Common questions
Will client data be used to train AI models?
The permitted uses of client data should be explicit in the engagement and provider terms. Our proposed default is no training or fine-tuning on client data without explicit, documented authorisation. Third-party provider retention and training terms must be checked for the selected account and service before data is connected.
How do you handle PII in AI pipelines?
The design starts with a data inventory and a decision about whether personal data is necessary. Minimisation, pseudonymisation, encryption, access, logging, retention, and deletion controls are then scoped to the actual systems and applicable requirements. Contractual roles and DPA needs must be confirmed for each engagement.
What happens if the AI makes a mistake in production?
The production plan should define who owns the incident, how the workflow pauses or falls back, what can be rolled back, which evidence is retained, and who must be notified. These are deployment-specific controls and should be demonstrated in acceptance tests rather than assumed from a general policy.
How do you stay current with AI regulation?
We use current official regulator and standards-body material when mapping requirements, record the source and review date, and identify questions that need qualified legal, privacy, security, or sector advice. Clarvia's technical guidance is not legal advice, and the responsible organisation remains accountable for its obligations.
Is Clarvia SOC 2 or ISO 27001 certified?
This page does not claim that Clarvia holds a SOC 2 report, ISO 27001 certification, HIPAA certification, or any equivalent attestation. Framework names describe references that may inform scoped control work. Ask for current, specific evidence before relying on any certification or compliance claim.
Ready to build AI you can trust?
Discuss the controls, evidence, and specialist review your use case requires.