Trust center · Shared responsibility
Shared responsibility: who does what in an AI project
An AI system touches your data, your accounts, third-party models and your customers. Every one of those layers needs an owner. This page sets out what we ensure, what you define and what the providers run, in the same terms as our contract.
| Criterion | MiniAI Labs ensures | You define and own | Providers run |
|---|---|---|---|
| Data | Uses your data only to deliver and support your project, asks for the minimum, and never reuses it to train systems for other clients | Own the data, confirm you have the right to share it, and decide what may reach AI providers | Process what your system sends under their own terms and retention settings |
| Accounts and keys | Sets accounts up in your name wherever possible and keeps keys in secret settings, never in code | Hold admin rights and billing, keep credentials secure and turn on multi-factor sign-in | Secure their platforms and sign-in systems |
| Models and AI providers | Recommends models and settings, including training opt-outs where offered, and names every provider in the proposal | Approve the providers and accept their terms for your accounts | Run, update and retire models, and may change prices or features |
| Channels: web, WhatsApp, phone, email | Configures each channel, including the disclosure and opt-out features it supports | Decide what your business must disclose, and follow consent rules for calls, messages and recordings and platform policies such as WhatsApp’s | Deliver messages and calls and enforce their own platform rules |
| Guardrails and AI output | Builds guardrails, tests before launch and adds a handoff to a person | Review AI output before relying on it, and keep a person in decisions that matter | Train and filter the underlying models |
| People and process | Gives access only to the people working on your project and hands over documentation | Name an owner for the system and the people who pick up handoffs | Run their own support and status channels |
| Security incidents | Tells you without undue delay and gives you what you need for your notification duties | Notify regulators or affected people where the law requires it, and revoke access if needed | Handle incidents on their platforms under their terms |
| Legal and compliance decisions | Builds HIPAA-aware where it matters and describes data flows in writing for your advisor | Decide, with your advisor, whether the setup meets your legal obligations | Offer agreements such as a BAA or data processing terms where available |
Detail
The details
Why the split matters
Most AI incidents are not exotic attacks. They are ordinary gaps: a key nobody rotated after a contractor left, a voice agent that never said it was an AI because nobody decided the wording, a model update that changed answers and nobody re-tested. Each of those gaps sits between two parties who both assumed the other had it. Writing the split down before the build closes them.
Where the split sits in our terms
- Your responsibilities, section 8: accurate information and timely access, the right to share your data, lawful use including consent and platform rules, and secure credentials.
- Ownership, section 7: once you have paid in full you own the deliverables, including configurations, knowledge bases, prompts and integration code; your data and accounts are always yours.
- Data and privacy, section 10: we use project data only for your project, limit access to what the work needs, and tell you about a security incident without undue delay.
- AI output, section 11: AI can be wrong, you review output before relying on it, and figures on our site are typical targets, not promises.
- Third-party services, section 12: neither of us answers for outages or changes in platforms neither controls, but we remain responsible for our own misconfiguration.
A handover checklist you can use
Before you sign off a build, check each line. If one is not true yet, ask us to close it before the final invoice.
- Admin rights on every account sit with a named person in your business, and our access is removed or limited to what a monthly plan needs.
- Every API key the system uses was issued from your accounts and is stored in platform secret settings.
- You have a written description of data flows, providers and who has access.
- You know who in your team receives handoffs from the assistant or agent, and through which channel.
- Your business has approved the AI disclosure wording for each channel.
- You hold the deliverables listed in the proposal: configurations, prompts, workflows, integration code and documentation.
- Third-party usage is billed to your business, so nothing stops if our engagement ends.
When the split changes
On a monthly plan we keep the access the plan needs and stay responsible for the changes we make under it. After a one-off handover, changes made by you or another developer are yours to own, though we can still help as quoted work. An Enterprise contract can move specific duties to us, such as defined security measures or a data processing agreement, and it says so plainly when it does.
FAQ
Frequently asked questions
If the AI gives a customer a wrong answer, who is responsible?
It depends on why. If our configuration caused it, for example a guardrail we set up badly, that is ours to fix and our liability follows the terms. If the model itself erred within a sound setup, the terms are plain that AI can make mistakes, which is why output that matters should be reviewed by a person in your team before anyone relies on it.
Who decides whether callers are told they are talking to an AI?
Your business does. We build the agents we deliver to disclose that they are AI by default, and we can set the wording, timing and opt-out, but the rules on disclosure, consent and recording differ by country and by industry. Your team, with advice where needed, approves the final wording for each channel.
Can another developer take over the system later?
Yes. Once you have paid in full you own the deliverables we made for you, and our terms give you a permanent licence to the reusable components inside them, explicitly including having another developer maintain them. Because the accounts are in your name, a handover means sharing documentation, not migrating infrastructure.
Who is responsible when an AI provider has an outage or changes a model?
Neither of us controls the provider, so neither of us is liable for its outages or changes. What we own is our part: designing for a fallback where the build allows it, and helping you adapt under your support plan or as quoted work. Where a provider change exposes a mistake in our own setup, that part is still ours.
Do we need our own accounts with the AI and telephony providers?
Wherever the provider allows it, yes, and we set them up with you. You then pay the provider directly and hold the admin rights. Where an account cannot be in your name, we say so in the proposal, and any cost we pay for you is billed at cost with no mark-up.
Questions about this page
If your organisation uses its own responsibility matrix or a vendor RACI, send it to hello@miniailabs.in and we will map our duties onto it before the proposal is final.
Next step
Have a workflow in mind? Let’s scope it together.
Book a free 30-minute strategy call. Bring one process you want to automate and we will talk through scope, integrations and a sensible first step.
Free 30-minute call · no commitment