AI Governance & Human Oversight

AI purpose

AI is used in narrow, defined places in our workflow. Its job is to help prepare and structure work for people, not to produce final answers. The supported capabilities are:

• Structure and normalize audit inputs — turning submitted operational and financial data into a consistent shape for analysis.
• Summarize status and process — the client-facing portal assistant explains where an engagement stands, what has been received, and what happens next.
• Surface anomalies and patterns — highlighting things in prepared data that may be worth a closer human look.
• Assist candidate analysis and prioritization — for example, scoring each leakage lever as a starting point that the audit team reviews.

AI is not used to make final determinations, to set the numbers a client sees, or to act without review. Capabilities that are not listed here are not claimed.

AI assists. Humans remain accountable.

Client-facing findings are subject to a controlled publication workflow. Alpha Scaling’s audit process includes human review before findings are finalized for client use.

Two design decisions make that principle enforceable rather than aspirational:

A human publish gate on every number

Client-facing findings — leak zones, dollar ranges, lever scores and confidence — live in a dedicated table where each row carries a publish timestamp (findings.published_at). Until the audit team publishes a finding, no client can ever see it: this is enforced in the database, where a client can read only their own organization’s published rows. A dollar figure or lever score may only be rendered from a published row. An engagement with no published rows shows a locked or preview state — never a placeholder amount, never a sample dial position — and any score is presented as the audit team’s conservative estimate, never as a verified-final guarantee.

An assistant that is barred from the numbers

The portal assistant is a status-and-process helper. Its instructions forbid it from stating, estimating or hinting at findings, dollar amounts, benchmarks, percentages or projected results, and from guaranteeing outcomes. For any question about money or results, it points the client to the verified report and to messaging the team. The verified report is where the numbers live.

Human oversight model

The workflow gives the audit team the controls, and the platform enforces them in code:

• Review. Staff can see findings whether or not they are published — the auditor needs to review drafts before anything is released.
• Publish or withhold. Setting the publish gate is the single act that puts a dollar figure in front of a client, and it runs through a server-side publish step that also records an audit event.
• Staff-only finding writes, enforced in the database. No signed-in session — staff included — can insert, update or delete findings directly; the findings table grants those privileges to no authenticated session at all. Staff actions instead run through SECURITY DEFINER functions that first verify the caller’s staff role and record every change to an append-only events log.

Beyond these code-enforced controls, the exact review, estimation and sign-off steps the audit team follows before publishing are described as an operational process: AI-assisted analysis, reviewed and published by the audit team.

AI data flow

A single model exchange moves through these stages. Nothing skips the human step at the end when it becomes client-facing.

1. 1User inputA signed-in user asks the portal assistant a question, or an engagement’s prepared inputs enter analysis.
2. 2Alpha Scaling processingThe request is authenticated and handled server-side; context is assembled from the caller’s own records.
3. 3Minimum necessary contextOnly task-relevant metadata — for example file names and statuses — is included. Document contents and financial figures are not sent.
4. 4AI provider (Anthropic)The minimized request is sent to the model provider over an encrypted connection.
5. 5Model responseThe model returns text — a summary or candidate analysis.
6. 6Back to Alpha ScalingThe response is received server-side. Nothing from the exchange is persisted except a single audit event.
7. 7Human reviewAnything that would become a client-facing number is reviewed and published by the audit team. Model output is never shown to a client as findings on its own.

Data minimization for AI

Only task-relevant information is included in a model request. The portal assistant’s context is built from the caller’s own engagement and is limited to labels and statuses, such as:

• the organization name and the engagement’s current stage and timeline;
• checklist item labels and their statuses;
• uploaded file names and their automated check verdicts;
• the names and versions of published deliverables.

It does not contain document contents, financial figures, or findings. Uploaded business and financial documents are processed server-side by the analysis engine and are never sent to the assistant.

Provider governance

We evaluate any AI vendor before relying on it, and re-evaluate on material change, against principles including:

• security posture and enterprise controls;
• privacy terms and data-handling practices;
• reliability and operational maturity;
• retention and model-training policy;
• contractual restrictions on the use of our data.

Our current AI provider is Anthropic (model Claude Haiku 4.5), which processes the minimized engagement metadata described above.

Prompt & output risk

Language models can be wrong. They may hallucinate, misread context, or produce output that is incomplete or inconsistent. We treat that as an inherent property of the technology, not an edge case.

Because of this, model output is handled as a draft input that is subject to contextual human review — never as a final, client-facing result on its own. This is precisely why the publish gate exists and why the portal assistant is not permitted to state numbers: a model mistake cannot, by design, reach a client as a finding without a person in the loop.

Prompt injection & adversarial input

User-supplied and uploaded content may contain misleading or embedded instructions that try to steer a model. The architecture is designed so that uploaded content is not treated as trusted, system-level instructions:

• The portal assistant’s context is built server-side from the caller’s own profile and records, not from request parameters — a caller cannot redirect the context or reach another tenant’s data through the request.
• Uploaded files are checked by deterministic server-side validation with no model in the loop, so a document cannot issue instructions to a model during that check.

Beyond these code-evidenced properties, broader resistance to prompt injection — for example systematic adversarial testing across every model touchpoint — is a governance principle we design toward, and we describe it as a principle rather than a finished, guaranteed control.

AI access control

• Authenticated only. The portal assistant is JWT-gated — every request must carry a valid signed-in session, which is verified before any context is loaded.
• Tenant-scoped server-side. A client’s context is assembled from their own organization’s records, so a client can only ever ask about their own engagement.
• Staff isolation. Staff callers receive a generic internal-test context that contains no client engagement data.

Usage & cost protection

AI usage is bounded on the server in two layers: per-request size caps, and rate limiting across requests over time.

Per-request size caps, enforced in the assistant:

• at most 20 messages per request;
• at most 2,000 characters per message;
• a 600-token ceiling on the model’s output;
• a 30-second timeout, with a single retry.

Rate limiting, beyond the size of any single request:

• per-user and per-organization rate limiting, using a rolling time window together with a daily ceiling;
• enforced server-side in the assistant edge function, as a control against abuse and runaway cost.

AI auditability

Every assistant exchange writes exactly one append-only audit event. That event records the actor, the action (assistant.message), the number of characters in the request, and whether the call succeeded.

The content of the exchange — the user’s message text and the model’s reply — is not stored. We keep enough to account for usage and diagnose failures, and no more.

Model change management

A change of model or provider is a material change. Before adopting one, we evaluate it for performance, security, data handling and output behavior, so that a swap does not quietly weaken any of the controls on this page.

This describes how we approach such changes as governance guidance. It does not represent a formal, independently governed change-control board.