The hardest part of putting an AI employee into a real business is not the model. It is everything around the model: what it is allowed to see, what it is allowed to do, how a human stays in the loop, and how you reconstruct what happened after the fact.
These are the design principles we are working into the BAKD AI prototype. We have not solved them. We are sharing them so the people we ask to trust us can see how we think about the problem.
1. Human in the loop by default
Anything that leaves the building, an email reply, a chat message, a customer-facing update, goes through a human approval step by default. The AI drafts. A person clicks send. The same rule applies to anything that changes data in a system of record: marking an order as paid, updating a customer record, closing a ticket.
Over time, a team should be able to dial down the approval gate for low-risk actions where the audit trail and past performance justify it. Our default is to start with the gate on for everything and earn the right to lower it.
2. Evidence-first answers
When the AI answers a question or drafts a reply, it should quote from approved sources rather than improvising. We build this with retrieval-augmented generation against a knowledge base the team controls.
A few rules we are committing to:
- If the AI cannot find evidence in the knowledge base for a question, it says so instead of guessing.
- Every answer can be expanded to show the underlying citations: which document, which section, which version.
- Knowledge has versions. If a policy changed last week, the AI quotes the current one and old answers do not silently drift.
3. Least-privilege tools
An AI employee, like a human one, should only have the access it actually needs. In practice that means scoping every tool, every API key and every integration to the smallest useful surface.
We use JSON-schema-validated tool calls so the AI cannot invoke something with fields it was not given permission for. Tools are grouped by risk. Read-only lookups can run without approval. Anything that writes, sends or charges requires an explicit approval step and is logged with the approver, the input and the result.
4. A full audit log
Every action an AI employee takes lands in an append-only log. The log records timestamp, actor (which AI employee or which human), workspace, object touched, action taken and outcome. The same log captures approvals, rejections and escalations.
The point of the audit log is not just compliance. It is how a team builds confidence over time. When someone asks “why did our support bot say that?”, we want a straight answer: here is the question, here is the retrieval, here is the draft, here is the human who approved it.
5. Treat retrieved content as untrusted
Prompt injection is real. If your AI reads emails, scrapes PDFs or pulls from a shared inbox, somebody will eventually paste instructions in there hoping to take it for a ride.
Our working approach: retrieved documents and inbound messages are data, not instructions. We strip and sandbox control characters, we apply a separate classifier to flag obvious injection attempts, and we never let retrieved text expand the tool surface the AI is allowed to call. The policy is enforced at the orchestration layer, not asked for politely in the system prompt.
6. AWS-first, model-flexible
On the infrastructure side, we are building on AWS: Bedrock for model access, S3 for documents, Aurora and RDS for structured data, Cognito for identity, and the usual supporting cast. We chose AWS because Malaysian SMEs and the partners they sell into are comfortable with it, and because the data-residency and security controls are familiar to anyone who has been through procurement.
On the model side, we keep our orchestration layer abstracted from any single provider. Bedrock gives us a portfolio of options, and we can route different tasks to different models, drafting, classification, retrieval reranking, based on cost, latency and quality. Nothing in the product should break if the best model for a job changes next quarter.
What we are not claiming
We are at the prototype stage. We do not claim SOC 2, ISO or any other formal certification today. We do not claim that this design is finished or that the implementation is complete. We claim that these are the principles we are building toward, that we will say honestly when something is shipped versus designed, and that we will keep the audit log open to the customer from day one.
If you want to dig into the details, or you have hard requirements we should be designing for, please tell us. A lot of this only gets right with feedback from real teams.