Our approach to Responsible AI.
The principles that guide how Avisha Global builds and deploys AI systems — for our own products and for clients.
Why this page exists
We build AI for clients and we sell AI governance, so warm sentiments here would be worth little. A principle with no mechanism behind it is decoration, so every section below names what enforces it: a document, a gate in code, a test, a log.
It covers AI we design, build or operate for clients — agents, automation, retrieval systems, private models, managed AI operations — and the AI we use ourselves. Where your own policy is stricter, yours governs. Where it is weaker on something we treat as non-negotiable, we raise it in writing before the build. If what you need is outside what we will build, we say so on the call.
Someone is accountable, by name
The most common governance failure we find is not technical. It is a production AI system nobody owns: built by a team that has moved on, used by a department that did not commission it. The search for an owner then starts after the incident.
So before go-live, each system has a named owner in the AI system register — a person, not a department — accountable for its purpose, who may use it, what failure is acceptable, and the decision to pause it. If nobody will put their name to a system, that is the finding. There must also be a working route to turn it off, and someone with the authority and access to use it.
Human checkpoints sit on anything hard to undo: money moving, customer communications at scale, record deletion, access changes. The checkpoint is a gate, not an instruction. A prompt saying “always ask before issuing a refund” is a request to a probabilistic system; a tool that cannot execute a refund without an approval token is a control.
One system, one purpose
At design time we write down the task, the inputs the system may see, who may use it, the decisions it may influence, and the uses that are out of scope. That goes into the design document and the register, and the owner signs it.
AI capability generalises; permission does not. A tool built to read supplier invoices will have a go at résumés; a bot built for delivery questions will answer a policy question it was never evaluated against, just as fluently.
So a change of purpose is a new system, not a configuration change: evaluation and data review re-run, legal basis re-checked, owner signing again. Scope creep is the moment an unevaluated system starts making decisions nobody tested it for.
Data: what goes in, and what is never used to train
Before a model sees data we want three things on paper: where it came from, your right to use it for this purpose, and that it is the minimum the task needs. For personal data that means a lawful basis under the Digital Personal Data Protection Act, 2023, with notice matching what the system does.
- Client data is never used to train, fine-tune or improve a model outside the engagement — not ours, not a vendor’s, not a shared one.
- Hosted model APIs are set to zero retention and no training where the provider offers it, with the setting named in the design document. Where one cannot, you hear so before the build begins.
- Retrieval enforces access control at retrieval time, not inherited from the source system. Otherwise the index becomes the most readable copy of everything you hold.
- Residency is designed in: in-region inference, named regions, no silent failover when capacity is tight.
- Development uses synthetic or redacted data, and no dataset of unknown provenance.
- Deletion propagates into vector indexes, embeddings, caches and prompt logs. An embedding derived from a deleted document is still derived from it.
Security is part of responsibility, not a later phase
A system that can be talked into doing the wrong thing is not responsible, however good its principles document reads. Our own builds get the methods we sell as AI red teaming.
- Least-privilege tool access: every tool an agent can call enumerated, credentials scoped per tool and per agent, read-only where reading is enough.
- Prompt injection tested, not assumed away — direct attempts, and indirect payloads through documents, attachments, web pages and tool responses; the payload need not come from the person typing.
- Untrusted content isolated from instructions, and output treated as untrusted before it reaches SQL, a shell, HTML or an email send.
- Loops and spend bounded; cross-tenant leakage tested explicitly.
- The attack set handed over as a regression suite, so the next prompt edit does not reopen a hole closed three months ago.
- Model risk assessed alongside security: a system can be secure and still unfit for the decision it makes.
Logging, auditability, and the register as the artefact
Months from now, can you explain to a customer, auditor or regulator why this system did this? If the logs cannot answer that, the design is not finished.
For each consequential action we log the input, the retrieved context, the model and prompt version, the tool calls, the output, who approved it, and the timestamp. An output you cannot attribute to a version cannot be reproduced. To be confirmed: default retention for agent action logs, and how it squares with minimisation and erasure duties.
The artefact that makes this inspectable is the AI system register: every model and agent, with purpose, owner, data, risk tier, last evaluation and next review. One current spreadsheet answers a regulator better than a policy document, and keeping it surfaces the systems nobody remembers commissioning. Where someone is dealing with an AI rather than a colleague, we design for them to be told.
These are principles. Turning them into something a board or a regulator can inspect takes an inventory of every model and agent, named owners, and evidence that oversight actually runs.
See AI GovernanceEvaluation before production, and after any change
A demo proves a system can work once. Evaluation establishes how often it works on your real task, and what it does when it fails. Test set and acceptance thresholds are agreed with the owner before the build, because thresholds negotiated afterwards settle wherever the system landed.
We measure accuracy on the real task rather than vendor benchmarks, the shape of the failures not the count, refusal behaviour, robustness to messy and adversarial input, and cost under load. What counts as good enough is a business decision, written down and signed.
Re-evaluation is triggered by change, not the calendar: a new model version including a provider’s own update you did not ask for, a prompt change, a new data source or tool, a change of purpose, or observed drift. And monitoring means reading sampled output — a system that is up and quietly wrong looks healthy on a dashboard.
Bias and fairness, handled honestly
What can be done: define the groups that matter, test whether outcomes differ across them on real data, probe deliberately for discriminatory output, and document what was measured and with what uncertainty. For consequential decisions about people, add monitoring and a route of appeal.
What cannot be done: certify that a model is unbiased. The training data carries history in it, the test set is finite and the world is not, and some attributes needed to measure fairness are ones you should not be collecting.
So our reports say what was tested, across which groups, with what result, and what the test does not cover — less satisfying than a clean bill of health, and the only version that survives scrutiny. If a client wants a line in a deck saying their model is unbiased, we will not write it.
Human oversight that is real, not a rubber stamp
“Human in the loop” is the standard answer to every AI risk question, and usually it is not true. The failure mode is specific: a reviewer approving everything, at a few seconds an item, hundreds of times a day. That is an approval log, not oversight.
Signs the oversight is theatre
- Approval rates at or near 100 per cent, month after month.
- Median review time shorter than it takes to read the item.
- Reviewers see the recommendation but not the evidence behind it.
- Overriding is slower or riskier than agreeing.
- Nobody can produce an example of a decision the human stopped.
So we instrument the oversight itself: approval rate, time on review, override rate, and where overrides cluster. Reviewers get the evidence, the authority to say no, time budgeted as real work, and sample-auditing of what they approved. If the override rate is zero for a month, either the system is flawless or the review is not happening.
Work we decline
- Covert surveillance of individuals, including employee monitoring designed to be undetectable, and profiling outside a lawful, disclosed basis.
- Deceptive synthetic media: cloning a real person’s voice or likeness for impersonation, fabricated endorsement, or content built to be mistaken for something they said.
- Systems built to evade regulators, auditors or lawful process — back-dated records, or documentation describing controls that do not operate.
- Fully autonomous consequential decisions about a person with no appeal route: loan rejection, claim denial, dismissal, admission or benefit refusal, decided end to end with no way to contest it.
- Scoring people on protected characteristics or proxies for them — caste, religion, community, gender, disability, or a postcode feature doing the same job quietly.
- Disinformation and coordinated inauthentic content, or re-identification of individuals from anonymised data.
- Offensive testing without written authorisation from the system owner. A client’s word that they “have a relationship” with the third party is not authorisation.
The list is not exhaustive, and it costs us work. We would rather lose an engagement than be the firm named in the case study.
Where this sits against emerging AI governance expectations
AI rules here and elsewhere are still being written, so anyone claiming their AI is “compliant” today is describing a moving target. The Digital Personal Data Protection Act, 2023 is law, and we treat it as a design constraint: purpose limitation, minimisation, valid consent or legitimate use, notice that matches reality, erasure that propagates, breach handling with the Data Fiduciary’s duties in view. Where you are the Fiduciary and we are the processor, the build is shaped so you can discharge those duties with evidence, not assertion.
We use published frameworks as structure: the NIST AI Risk Management Framework, ISO/IEC 42001 and 23894, the OWASP Top 10 for LLM Applications, and MeitY and sector-regulator guidance as it firms up.
Using a framework as a design reference is not certification against it, and we will not blur the two. Avisha Global is not certified or independently assessed against ISO/IEC 42001 or any other AI management standard, and makes no EU AI Act conformity claim — though we design to its risk-tiering logic where it applies. Certificates come from accredited bodies; we produce the evidence that stands up when they arrive. To be confirmed: review cadence for this page and a visible last-reviewed date.
Holding your own AI to this standard?
We inventory the models and agents you are already running, red-team them, and put oversight and monitoring in place before they reach production.