The concern worth taking seriously
Organizations evaluating an AI vendor usually have two distinct worries, and it helps to separate them.
The first is a data worry: will our confidential material end up training somebody’s model, sitting in a third-party log, or leaking into another customer’s answers. This is a contractual and architectural question with clean answers.
The second is a trust worry: if a system tells my board that a project is at risk, can I find out why it said that, and can I overrule it. This is a design question, and it is the one that decides whether an AI system is usable in a serious operational or research environment. A system that produces confident, unattributable assertions is worse than no system, because people act on it.
We treat both as first-order requirements.
No training on client data
No client data is used to train, fine-tune, or improve any model that serves anyone other than that client. This holds in all deployment models.
Where we use third-party inference providers, we use enterprise API tiers whose terms contractually prohibit training on submitted content and provide zero or minimal retention. We do not use consumer AI products for client work, and we do not permit client content to be pasted into personal AI accounts — that is an explicit disciplinary matter in our acceptable use standard, not a guideline.
Where a client requires that content never reach a third-party inference provider at all, we run open-weight models on GPU capacity we operate for that client alone. No external model API is in the path. See Hosting, isolation, and AI processing for what that means concretely, because the phrase “local AI processing” gets used loosely in our industry and we would rather be precise than reassuring.
Data minimization before inference
The most reliable way to protect data from a model is not to send it. Our pipelines are built to reduce what reaches an inference call:
We extract only the portion of a document or transcript relevant to the current task rather than submitting whole corpora. We strip or tokenize identifiers that the task does not require. We prefer deterministic code over model calls for anything a parser can do reliably — dates, amounts, identifiers, and structured fields do not need a language model. We cache and reuse structured results instead of re-submitting the same source material.
This is partly a cost and latency discipline, and it happens to be the strongest privacy control available.
White-box by construction
Our systems are built so that every assertion can be traced back to its origin. This is the design principle we describe as white-box, in contrast to a model that emits conclusions with no accounting.
Concretely: every extracted fact carries a link to its source — the specific meeting and timestamp, the message, the document and section, or the API response — recorded when the fact was created. Confidence is surfaced rather than hidden, so a low-confidence extraction is visibly low-confidence. Consequential updates are proposed, not applied: the system drafts a status change, a risk, an action, or an owner, and a named human confirms, edits, or rejects it. Confirmations, edits, rejections, and overrides are all attributed and retained, which means we can also learn from rejections to improve extraction quality. Nothing in the audit trail is editable by the pipeline that wrote it.
The practical consequence is that when a leader asks “who said this project slipped, and when,” the answer is a specific sentence in a specific meeting, not a model’s impression.
Autonomy is a setting, not a default
Some of what we build can act autonomously — trigger a workflow, notify an owner, open a task, generate a report. Whether it does so is a decision the client makes per action type, and the default is human confirmation.
We categorize actions by consequence. Reading and summarizing is low consequence and runs freely. Writing into a client system of record, notifying people outside the immediate team, or changing anything a person will be measured against is high consequence and requires confirmation unless a client explicitly enables automation for that action after a pilot period. Anything with a safety, regulatory, or financial dimension stays under human confirmation regardless.
We do not deploy agents with standing write access to safety-critical or operational-control systems. In environments where an incorrect automated action could affect physical operations or personal safety, our systems observe and advise; they do not actuate. That boundary is stated in the critical infrastructure annex and does not move without a formal, documented risk assessment.
Accuracy is managed, not assumed
Extraction from human conversation is imperfect, and a vendor claiming otherwise is either inexperienced or selling. We manage accuracy explicitly: we build an evaluation set from real, client-approved examples during onboarding, measure extraction precision and recall against it, track human rejection rates in production as a live quality signal, and review prompt and model changes against the evaluation set before release rather than shipping and hoping.
Model and prompt changes are treated as changes to a production system and go through change management. When a provider deprecates or silently updates a model, we re-run evaluations before adopting the replacement. AI evaluation and accuracy management covers the method and the numbers we report.
Uses we will not build
We decline work that uses AI to score, rank, or surveil individual employees; to make or materially inform employment decisions; to infer protected characteristics, health status, or emotional state; to draw clinical or diagnostic conclusions; or to take autonomous control of physical or safety-critical operations.
Our systems are built to make work visible, not people. When a system surfaces that a person is over-allocated, the purpose is workload planning, and we design the output to serve that purpose rather than individual performance management. This is a stated constraint in our AI risk assessment, and it is a boundary we hold even when asked.
Related detail
AI model register lists approved models, providers, regions, and retention terms. Provenance and human oversight documents the audit data model. AI risk assessment covers failure modes and mitigations.
