Responsible AI Policy.

Last updated: August 16, 2026

1. Why we wrote this

The whole reason we built a private-LLM and sovereign-AI practice is because public-cloud AI is, today, an unstable foundation for a business that needs to be predictable. Deprecation, downtime, price changes, policy drift, and data egress are not theoretical. They are the daily operating conditions of cloud-frontier AI. So our stance is not "be responsible about AI in the abstract." It is: if a model is going to make decisions that affect your business, your clients, or your compliance posture, that model should be yours to own, yours to inspect, yours to operate, and yours to walk away from.

This policy describes how we make that real, and the principles we apply to AI systems of any kind.

2. Our principles

1. Sovereignty. Open weights, your fine-tunes, your hardware, your VLAN. We do not believe in AI that can be turned off by a third party for reasons that have nothing to do with your use of it.
2. Transparency. We tell you what model is in use, where data flows, what is logged, and how to opt out. See our AI Disclosure.
3. Human oversight. A named human owns the final call on any workflow that affects a person, a regulated decision, or a material business outcome. AI never ships to production without human approval.
4. Honesty about accuracy. AI outputs are probabilistic and may be wrong. We do not claim "accuracy" in marketing. We tell you where verification is your responsibility and we provide the tools to do it.
5. Bias and safety review. We red-team systems we deploy for prompt-injection resistance, jailbreak resistance, data exfiltration, and bias on the dimensions relevant to the engagement.
6. No dark patterns. We do not design AI features to manipulate, deceive, or extract consent under duress. We do not deploy AI for surveillance of individuals, for social scoring, or for any use prohibited by our Acceptable Use Policy.
7. No training on you. We do not train foundation models on client data. For fine-tuning, the SoW says exactly what runs, on what data, and where the resulting weights live.
8. Right to walk away. We deliver weights, code, configs, and runbooks so that you can operate the system without us, and so you can take it to a competitor if we ever become one.

3. The lifecycle we follow

For every AI system we deploy for a client, we follow this lifecycle and document the outputs in the engagement's runbook:

1. Use-case review. Is this a use case we will take? Does it conflict with our AUP, our principles, or applicable law? What is the worst-case failure mode?
2. Model selection. Pick the smallest, cheapest model that meets the requirements. Prefer open weights. Prefer your fine-tunes. Avoid frontier models where a smaller model suffices.
3. Data review. What data trains the system, what data is in retrieval, what data is in prompts at inference time. Tag data for retention and redaction. Document flows.
4. Evaluation. Build an eval suite tied to your real tasks, not a public benchmark. Track regressions.
5. Red-team. Test for prompt injection, jailbreaks, data exfiltration, bias, and the specific failure modes of the use case.
6. Human-in-the-loop design. Where the system can affect a person, design the review checkpoint explicitly: who reviews, on what signal, with what authority.
7. Deployment guardrails. Rate limits, content classifiers, prompt-injection defenses, audit logging, kill-switch.
8. Monitoring. Drift, accuracy, latency, refusal rate, jailbreak attempts, user feedback. Alerts go to humans.
9. Incident response. AI-specific incidents are within scope of our incident-response procedure.
10. Sunset and migration. When the system is replaced, we archive what you need, deprecate the rest, and document the migration.

4. Data we will and will not use

4.1 Will use, with consent and contract

• Client-provided data for fine-tuning, where the SoW names the dataset, the objective, the retention, and the recipient of the resulting weights.
• Public, permissively licensed data for retrieval-augmented generation (RAG), with provenance tracked.
• Synthetic data we generate for evaluation and red-teaming, clearly labeled.

4.2 Will not use

• Personal data processed on behalf of a client, for any purpose other than the documented instruction.
• Data from a third party's terms of service that prohibit downstream AI use.
• Illicit content per our AUP.
• Government identifiers, biometric data, or any other category we are prohibited from processing by law or contract.

5. Evaluation and red-teaming

We build eval suites tied to your tasks. A few examples:

• Legal contract review. Precision and recall on a labeled set of clauses you provide; agreement with senior-reviewer on flagged issues.
• Accounting workpaper drafter. Reconciliation accuracy on a labeled set of trial balances; agreement with the human reviewer.
• Customer support triage. Routing accuracy, deflection rate (where appropriate), and CSAT impact.

Red-teaming covers prompt-injection, jailbreaks, data exfiltration, persona attacks, and bias on the protected categories relevant to the deployment (race, gender, age, disability, language, etc.). Sovereign customers get a joint pre-launch review with their compliance team.

6. Human oversight

The level of human oversight is matched to the impact of the decision:

• High impact (employment, credit, healthcare, legal). Human approval required before any output is acted on.
• Medium impact (internal triage, drafting). Human review of a sample plus all flagged outputs.
• Low impact (summarization for human readers). Human review of outputs the user requests.

The reviewer is named in the SoW or runbook; the system is designed so the reviewer's approval is the gate, not a rubber stamp.

7. Transparency and disclosure

We publish our AI Disclosuredescribing where AI is used in our services, what data flows where, and how to opt out. For each engagement we publish a model-and-data fact sheet in the SoW or a runbook attached to it.

8. Sovereignty and the public-cloud problem

For a deeper treatment of why we default to local / private / dedicated inference for client work, see our consulting page and the failure-mode list on it. The short version: a public-frontier model is, today, a single point of failure for any product or workflow that depends on it. We do not sell that risk to our clients.

9. AI incidents

An "AI incident" includes prompt-injection attacks that succeed, jailbreaks that produce harmful content, model regressions that produce materially wrong outputs, bias incidents that produce discriminatory outcomes, and data exfiltration through prompt or retrieval channels. AI incidents are within scope of our incident-response procedure. Good-faith research on our AI systems is covered by our responsible disclosure policy.

10. Governance

We review AI deployments weekly for the first 30 days, monthly for the first year, and quarterly thereafter. Sovereign customers get a quarterly AI governance review with their leadership. Material changes to this policy are reflected in your SoW or in advance notice.

11. How we update this policy

We treat this as a living document. It is reviewed every quarter and after any material AI incident or regulation. Material changes are announced at legal@empowered.guru subscribers and reflected in your SoW.

12. Contact

AI policy: ai-policy@empowered.guru. For security research on our AI systems, see responsible disclosure.

See also: AI Disclosure, Export Control, Regulatory Coverage.