AI/ML Governance Policy

We sell AI governance. We'd be hypocrites not to apply it to ourselves. This document is our internal AI governance policy: the same controls we recommend our customers apply to their agents, applied to ours.

It's also the policy our compliance staff are trained against and the framework our Ghost Audit pipeline enforces on APIR's own AI usage.

This policy applies to every AI system operated by APIR Intelligence (RIPA PTY LTD, ABN 48 638 569 632) on the apir.ai platform and in internal tooling. It covers model selection, deployment, monitoring, incident response, and decommissioning.

It does not cover AI systems operated by our customers on top of the platform: those are governed by the customer's own policies, with APIR keeping the evidence record.

Every AI system at APIR meets seven principles before it goes live:

1. Useful. The feature has to demonstrably help users do something faster, more accurately, or with better evidence than the non-AI alternative. “Cool demo” is not a justification.

2. Honest. Outputs are labelled as AI-generated. We do not pretend AI is human, and we do not hide which model is doing the work.

3. Human-overseen. A human can review, override, or disable every AI output that meaningfully affects a customer. There are no “final-say” AI decisions about people.

4. Privacy-minimised. The minimum data necessary to perform the task is sent to the model. No Customer Data is used for training.

5. Tested for bias. Features that score or rank entities are tested against synthetic datasets representing protected characteristics before launch and quarterly thereafter.

6. Reversible. AI actions are reversible: drafts can be deleted, scores can be regenerated with a published methodology, and any user can request a rollback to a pre-AI state.

7. Audit-trailed. Every AI inference logs model, prompt template, response hash, and reviewer. Records are tamper-evident via SHA-256 chain.

Before adopting a model, we evaluate it on five gates:

Safety record: the provider's published safety policies, red-team results, and known failure modes are documented. We prefer providers with public model cards and constitutional AI / RLHF evidence.

Data handling: the provider must contractually prohibit training on our inputs. Zero-retention endpoints are required for compliance-sensitive workloads.

Capability fit: the model is benchmarked against the specific task (compliance drafting, regulatory summarisation, conversational guidance) on a held-out evaluation set we maintain internally.

Geographic & legal stance: the provider operates in a jurisdiction with workable data protection law and a published policy on government data requests.

Operational maturity: rate limits, SLAs, monitoring APIs, and incident communication history are reviewed.

Current primary models: Anthropic's Claude family, called directly. Fallback: other model providers through OpenRouter, and Google's Gemini API for search and bulk work, as listed in the DPA. Provider changes require Founder sign-off and a 30-day customer notice via this page.

Three of our AI features touch decisions that could disparately impact protected groups: compliance assessment drafting, insurance score sub-narratives, and trust score commentary. For each:

Quarterly bias audit. A held-out test set of agent profiles, constructed to vary along provider, model size, jurisdiction, and use case, is run through the feature. Output variance is measured. If variance correlates with protected characteristics beyond a published threshold, the feature is paused.

Reviewer rotation. Human reviewers on AI-drafted findings rotate weekly, so no single perspective sets the editorial tone.

Customer feedback loop. Every AI output has a “flag this” affordance. Flags route to a queue that the compliance team triages within 48 hours.

Audit reports are summarised quarterly in the Trust Genome Methodology document and detailed reports are available to enterprise customers on request.

Five operational controls run on every AI feature in production. Each is monitored, audit-logged, and triggers a P0/P1 in our incident response plan if it degrades.

5.1 Content filtering. Every model response passes through an output filtering layer that screens for harmful content prevention: unsafe code execution, prompts to download arbitrary files, financial advice without disclaimers, regulated-profession output (medical / legal / tax). The filter is layered on top of the provider's own safety stack, not a replacement for it.

5.2 Output monitoring. A quality assurance pipeline samples 5% of AI output daily for human AI output review. Samples are scored against an internal rubric (factual accuracy, framework citation accuracy, tone fit, regulatory currency). The output monitoring queue feeds back into prompt-template revisions and provider re-evaluation.

5.3 Fallback mechanism. Every AI feature has a human fallback. When the model is unavailable, returns an empty response, fails a guardrail, or the user explicitly asks for a person, the feature triggers an escalation to human, surfaced as a banner with a direct route to the compliance team. SENTINEL chats route to a real inbox monitored during business hours.

5.4 Error handling. Standardised error handling across all AI endpoints: rate-limit, timeout, content-policy, provider-outage, and validation errors each map to a typed response with a remediation hint. Graceful degradation is the default: if Claude is down, we fail closed for compliance-sensitive surfaces and show a placeholder with the affected feature's failure mode documented inline, rather than silently delivering a degraded experience.

5.5 Bias detection. Bias monitoring runs continuously on Trust Genome and Insurance Score outputs, with quarterly fairness testing audits on AI-drafted compliance findings. The bias detection harness uses a held-out synthetic dataset that varies along provider, model size, jurisdiction, and use case; output variance correlating with protected characteristics beyond a published threshold pauses the affected feature pending review.

Different features have different human-in-the-loop requirements:

Mandatory human approval: compliance assessment publication, attestation issuance, kill-switch activation. AI may draft; a human must approve before the action commits.

Human-on-the-loop: SENTINEL responses, regulatory radar summaries, enrichment data. AI executes autonomously; humans can intervene, edit, or rollback at any time.

Human-out-of-the-loop: none. APIR does not operate any fully autonomous AI feature that affects customers.

Our compliance team is on duty during Australian business hours (UTC+9:30 / UTC+10:30) and rotates on-call coverage outside those hours for incident response.

An “AI incident” is any event where an APIR AI system produces an output that causes: or could cause: harm to a user, a third party, or the integrity of compliance evidence. This includes hallucinated regulatory citations, biased findings, leaked context, or unexpected behavioural drift detected by our own Ghost Audit pipeline against our own AI.

Reporting: incidents can be reported by anyone: customers, staff, third parties, at incidents@apir.ai. Reports are confidential by default. We respond within 24 hours.

Triage: incidents are classified within 24 hours as P0 (active customer harm), P1 (potential harm, no confirmed impact), P2 (policy violation, no harm), or P3 (informational).

Containment: P0 incidents trigger an immediate disable of the affected AI feature org-wide via our internal kill-switch. Customers are notified by email within 4 hours.

Resolution: root cause analysis is completed within 7 days for P0/P1 and posted to a public incident report at apir.ai/incidents (the page is created when the first incident occurs, we have not yet had one).

Regulator notification: P0 incidents involving EU users are reported to the relevant supervisory authority within 72 hours where required by GDPR Article 33 or by EU AI Act post-market monitoring obligations.

When we retire an AI feature or switch model providers, we follow the same protocol we recommend to customers:

A 30-day notice on this page. A migration path documented in our blog. Existing AI-generated artifacts (findings, summaries) are preserved with their original model attribution. The decommissioned model's API key is rotated out of edge function secrets within 24 hours of cutover.

This policy is aligned to the following frameworks. We map our internal controls to each annually:

EU AI Act (Reg. 2024/1689): Articles 5, 9, 13, 14, 17, 52, 72.

NIST AI Risk Management Framework (AI RMF 1.0): GOVERN, MAP, MEASURE, MANAGE.

ISO/IEC 42001:2023, AI Management Systems.

OECD AI Principles: inclusive growth, human-centred values, transparency, robustness, accountability.

Australian AI Ethics Principles (DISR): human-centred values, fairness, privacy & security, reliability, transparency & explainability, contestability, accountability, human oversight.

AI Risk Owner: Slav Ripa, Founder & CEO. Accountable for this policy and its enforcement.

Data Protection Officer: contactable at dpo@apir.ai.

Compliance Team: staffed during Australian business hours, monitors incident inbox, reviews AI-flagged outputs.

External advisors: we maintain advisory relationships with ASRO (independent verification layer) and a panel of external counsel for jurisdictional questions.

This policy is reviewed every 6 months or whenever:

• a new AI feature ships
• a primary or fallback model provider changes
• a P0 or P1 incident occurs
• EU AI Act, NIST AI RMF, or ISO 42001 publish a material update

The next scheduled review is November 24, 2026. Material changes are notified by email to customers and posted at apir.ai/blog.

Questions about this policy: dpo@apir.ai

Report an AI incident: incidents@apir.ai

Press inquiries: press@apir.ai