Voice AI for regulated teams: approvals, roles and audit trails

In a regulated business, the question about a voice agent is rarely "can it hold a conversation?". It is "who decided what it says, who approved it, and can you prove it?". A lending team cannot let one person quietly edit the script of a live collections agent. A healthcare provider has to show who started a campaign to several thousand patients, and when.

This post walks through the controls Graine gives teams like these: roles, approvals, audit, separate workspaces, deployment and calling windows. None of them is an add-on. They are how the platform works for every account, with switches your administrators set.

Roles that match how your team works

Everyone in a workspace has a role, and the role decides what they see, what they can change and what any API key they create can do. The same rules apply in the dashboard, in its API routes and in the public API, so a person's role is the same wherever they act.

Under the roles sit individual permissions, such as agents.edit, campaigns.run, audit.view and approvals.review, so a custom role can be as narrow as the job. Access can also be limited to particular agents, so a team lead works only with their own team's agents. A few rules hold whatever you configure:

• Nobody can grant a permission they do not hold themselves, and only an Admin makes someone an Admin.
• A workspace always keeps an Admin.
• A key a Member creates can never do more than that Member can.
• A role change takes effect within about a minute and never signs anyone out.

Maker–checker approvals for live agents and campaigns

Most control failures are not malicious. Someone edits a live script to fix a typo and changes a disclosure by accident. Maker–checker approval makes every change that matters a request that a second person reviews, like a pull request for your calling.

When your workspace turns approvals on:

• Going live is a request. A Member's agent stays a draft until an Admin approves it.
• A change to a live agent is a proposal. The live agent keeps taking calls exactly as it was while the change waits for review.
• Starting to dial is a request. Running a campaign list waits for approval before a single call is placed.
• Nobody approves their own request. An Admin who did not make it approves, rejects or asks for changes, and an approved change is applied exactly as proposed, credited to the person who asked.

Member (maker)                            Admin (checker)
--------------                            ---------------
edits the live "Renewals" agent
saves: "Propose changes"        ------>   request in the inbox, with
the live agent keeps calling,             what changes, who asked, and why
unchanged                                 approve  ->  applied exactly as proposed
                                          or ask for changes, or reject

The API follows the same rules. A change sent with a Member's key to a live agent comes back as 202, held for review, instead of being applied:

{
  "status": "pending_approval",
  "code": "approval_required",
  "detail": "Sent for review: “Payment reminders” is live, so these changes wait for a workspace admin's approval. The live agent is unchanged (request #12).",
  "approval_request_id": "apr_5c1f0e9a7b2d43e8a6f1"
}

If your policy requires it, Admins can be made to ask too.

An audit trail you can verify yourself

Every change a person makes in the dashboard, and every state-changing API action, writes one row to your organisation's audit trail: who acted and in what role, what changed and when, and whether it was allowed. Refused attempts are recorded too, which is often what an auditor asks about first. Rows identify people by their account and role, and do not copy customer details into the log.

The trail is append-only and hash-chained: each row's hash covers the row before it, so an edited or deleted row shows up as a broken link. Admins read and export it from the Activity log, and you can check the whole chain at any time through the API, or re-verify an exported copy independently, outside Graine.

Sub-accounts with their own wallets

Large organisations rarely run one team. A sub-account is a separate workspace inside your enterprise account, for a business line, a region or a client: its own agents, call history, campaigns, API keys, team and credits.

• Money stays separate. Each sub-account has its own wallet by default, funded from yours, or it can use your credits with an optional monthly limit.
• Your rules are the floor. A sub-account can make its approval rules stricter than yours, never looser.
• Access is per person, per sub-account. Someone can be an Admin in one, a Member limited to two agents in another, and absent from a third.

Deployed where your data must live

Data residency is often the first question in a security review, so there are three ways to run Graine:

• Shared cloud, operated by us, with tenancy enforced on every request.
• A dedicated instance, operated by us, in the region you choose, with compute, storage and capacity that serve only you.
• Deployed in your own cloud or data centre, operated by you. Call audio, transcripts, agent configuration and provider credentials stay inside your network. Funding checks and metering still reach our hosted billing over HTTPS, so this is not an air-gapped install, and we say so plainly.

Calling windows

Regulators care about when you call, not only what you say. Every agent can have calling hours, and each campaign has its own working hours in the time zone you set for it. A call that comes due outside the window, including a retry, is moved to the next open window instead of being placed at the wrong hour. Calls to users inside your app follow the same hours in the user's own time zone.

Where we are on compliance

SOC 2 Type II and ISO 27001 are in progress. Until they are complete, we will not imply otherwise. What we can do today is answer your security questionnaire in writing, provide architecture detail, and put the engineers who built these controls on a call with your reviewers.

Talk to us

If your team works under a regulator, we would like to hear what your reviewers will ask. Write to us at hello@graine.ai, or create an account and explore the controls in a workspace of your own.