Responsible AI
Responsible AI, stated honestly.
AI systems are probabilistic. They can be wrong, incomplete or misleading. We design for human oversight, evidence-backed outputs and clear allocation of responsibility.
[ Principles ]
What we design around.
Human oversight
Consequential decisions and actions keep a human in the loop, by default — especially where an agent can touch data, money, or customers.
Evidence & citations
Where an AI system makes a claim from source documents, we design it to show its sources, not just an answer.
Evaluation before trust
Systems are tested against representative cases before they're relied on for real decisions — not assumed to work because a demo went well.
Least privilege for agents
Agents get the narrowest set of tools and data access the task requires, with approval gates on anything consequential.
Transparency about limits
We tell customers what a system is and isn't validated for, rather than letting confidence in the demo substitute for evaluation.
[ Human-in-the-loop systems ]
Oversight is a level we choose per task, not a blanket policy.
"Human in the loop" means different things depending on the stakes. We size the level of human involvement to the consequence and reversibility of what the system is doing, and make that level explicit in the design rather than leaving it to how the system happens to behave.
Human-in-the-loop
A person approves before the action happens. Default for anything consequential or hard to reverse.
Human-on-the-loop
The system acts within pre-approved limits while a person monitors and can intervene — used once a workflow has an evaluated track record.
Human-out-of-the-loop
Reserved for low-stakes, easily reversible, well-evaluated tasks — always with logging that supports after-the-fact review.
By default, systems that touch money, customer-facing communication, or data outside their original scope run human-in-the-loop. Escalation paths and approval decisions are logged, so the record of who approved what is auditable — not reconstructed from memory after something goes wrong. See AI Agents & Autonomous Workflows for how this is implemented architecturally.
[ AI output limitations ]
What AI systems can get wrong.
Any AI system we build or deploy — ours or a third party's — can:
Users and customers remain responsible for verifying outputs before relying on them for critical decisions.
[ Governance, policy & standards ]
Governance is a set of decisions we can show you, not a poster on the wall.
For engagements that need a formal AI governance program, we structure one around the areas below. The specific policies, approval thresholds and documentation requirements are scoped to your risk profile and regulatory environment — a customer support assistant and a system that touches financial approvals don't need the same level of process.
Model risk management
Before a model or system goes into production, we document what it's for, how it was evaluated, and what its known failure modes are.
Data governance
What data an AI system can access, how it's sourced, and who's authorized to provide it are defined explicitly — not left implicit in a prompt.
AI risk assessment
We assess engagements for where AI error would matter most — safety, compliance, financial, reputational — and weight oversight accordingly.
Deployment governance
Moving a system from pilot to production is a defined step, not an accident of usage growing. Approval gates apply to expanding an agent's scope or autonomy.
Monitoring & audit trails
Production AI systems log their inputs, outputs and actions to a level that supports audit, debugging and incident review.
Incident response
If an AI system produces a materially wrong or harmful output in production, we treat it as an incident — with a defined process, not an ad hoc scramble.
On standards
Our governance practices are informed by established approaches to AI risk management, including risk-based frameworks such as the NIST AI Risk Management Framework and management-system standards such as ISO/IEC 42001. Blue Iceberg is not currently certified against ISO/IEC 42001 or any other AI management standard — where we reference a framework, we mean our practices draw on it, not that we hold formal certification. For engagements that require certified compliance, we scope that explicitly as part of the engagement.
Where a system falls under the EU AI Act, we assess it against the obligations that apply as part of our AI Act compliance assessment.
[ Responsibility ]
Who's responsible for what.
Blue Iceberg
- Designing systems for human oversight where consequential decisions are involved
- Evaluating systems before they're relied on for production use
- Being transparent about a system's known limitations
- Logging and monitoring to support audit and incident review
Customer
- Decisions made using AI outputs
- Human review where required by policy or regulation
- Industry-specific regulatory compliance
- Accuracy of customer-provided data
- Authorization and rights to provide data used by the system
- End-user usage and access credentials they provide
FAQs
Do you guarantee the AI is accurate?
No — unless an explicit, measurable SLA or acceptance criterion is agreed as part of the engagement. Outputs require human review for critical decisions.
Who's responsible for decisions made with AI?
The customer remains responsible for decisions, regulatory compliance and verifying outputs before relying on them — see the responsibility split above and the engagement Terms.
Can you help us build an AI governance program, not just use one?
Yes — this is part of AI Strategy, Governance & Evaluation. We help define the policies, approval thresholds and evaluation practices for your own AI systems, not just the ones we build.
Need a governance framework, not just a system?
We scope AI governance work independently of implementation — useful if you need the policy before you need the build.