---
title: "Responsible AI — Mili"
description: "How Mili governs its AI for financial advisory firms: the AI management system, each agent and its controls, supervision of AI output, prohibited uses, data and retention, change control and evaluation, fairness testing and incident response."
url: https://getmili.ai/responsible-ai
---

# Responsible AI at Mili

**Last updated:** 9 October 2026

This notice is written for the compliance, supervision and risk teams of the firms that use Mili. It sets out how our AI systems are governed: what they do, the limits we hold them to, where a person at your firm decides, what happens to your data, and how we test, change and monitor the systems. It summarises the policies of our AI management system, which are available for due diligence.

## Our position

Mili is an application layer. We do not train, fine-tune or otherwise alter the weights of any foundation model. We select third-party models through evaluation, and we govern what surrounds them: the instructions they receive, the tools they may call, the data they are given, and the approval gates between what they produce and anything that leaves Mili.

Our AI is assistive. It prepares drafts, analyses and proposed actions for licensed professionals and their staff. Everything our AI produces is a draft until a person at your firm accepts it. Nothing it produces is sent to a client or written to a system of record without that person’s approval.

## Governance and accountability

We run an AI management system designed to ISO/IEC 42001:2023, and we are working towards certification. It sits alongside the information security management system behind our ISO/IEC 27001:2022 certification and SOC 2 Type 2 report, and it uses the same access, change and incident controls.

- **Named owners.** Every AI system and every AI risk has a named owner. One owner is responsible for models, prompts, evaluations and AI features. A second owns infrastructure, security, logging and AI incident handling. A third owns AI vendors and contracts, training, consent and customer documentation. Our CEO approves AI policies, any exception to them, and the acceptance of residual risk.
- **Monthly management review.** Our AI Management Review meets every month. It approves new AI providers and material model changes. It reviews AI risks, incidents, evaluation and bias-test results, changes at our providers, and the progress of corrective actions. Its minutes and actions are kept as records.
- **Risk register and impact assessments.** AI risks are recorded in a register, scored for impact and likelihood, and reviewed monthly; the register is fully reassessed every year. Only low risks are accepted without treatment. An AI system impact assessment is required before we release a new AI system or give the assistant a new ability to write to an external system. It considers advisors, their clients, and meeting participants who are not Mili users.
- **Policies under document control.** Our AI policies are versioned and approved, and reviewed at least once a year and after any significant change. Every employee must accept them. Everyone who works on our AI systems completes AI management-system training.
- **Frameworks.** Our controls are designed to be consistent with ISO/IEC 42001 and the NIST AI Risk Management Framework. Where they apply to your firm, they are also designed for model risk management guidance (SR 11-7 and OCC Bulletin 2011-12), the Gramm-Leach-Bliley Act and SEC Regulation S-P, the books-and-records rules (SEC Rule 17a-4 and FINRA Rule 4511) as your firm configures them, and federal and state recording-consent laws.

## The AI systems in scope

The management system covers the whole platform: the web app, the desktop apps, the browser extension, and the iOS and Android apps. These are the AI systems inside it.

- **Meeting intelligence.** Transcription, notes, action items, follow-up emails, CRM updates and meeting preparation.
- **The Mili assistant.** About 60 skills across research, email, CRM, documents, forms and planning. The agents below are built from these skills.
- **Client operations.** Actions the assistant takes in an advisor’s own signed-in session of a connected platform, through the Mili browser extension.
- **Capture.** Online meetings are captured by the Mili meeting bot or desktop capture; in-person meetings and calls by the mobile apps. Transcription runs on our servers through AssemblyAI (by default) or Deepgram. The mobile apps sometimes fall back to transcribing on the device.

## Our agents and their controls

Each agent is a set of assistant skills governed by the same policies. For each one, we describe what it does, what it can reach, and where a person at your firm decides. Agents in early access are not yet generally available. Before release, each one goes through the validation and release procedure described below, including an impact assessment if it gains the ability to write to an external system or if it describes people.

### Meeting Agent

**Available.** Prepares briefs from CRM history, earlier meetings and open action items. It captures and transcribes the meeting, drafts notes, action items and a follow-up email, and proposes CRM tasks and updates. Notes remain drafts until the advisor finalises them, and both version history and edit history are kept. After a period your firm sets, finalised notes can be locked against further editing. The advisor applies CRM updates; Mili only proposes them. The follow-up email is sent only after the advisor approves it in Mili.

The agent surfaces life events and planning opportunities that were discussed; it does not infer traits about the people in the meeting. It also shows advisors per-meeting engagement, retention, revenue and satisfaction indicators. Under our policy, these indicators may not use voice or protected characteristics. Because they describe people, they are subject to an impact assessment and fairness testing, which the management review oversees.

### Scheduling Agent

**Available.** Finds available times across the calendars you connect, drafts invitations with agenda and location, and sets up reminders by meeting type. Each user grants calendar access through their own sign-in, within permissions your administrators set. Invitations and emails to clients go out only after the user approves them.

### Data Management Agent

**Available.** Proposes updates to client records across Salesforce, Advyzon, eMoney, Redtail and Wealthbox. Salesforce includes Financial Services Cloud, Practifi, Salentica and XLR8. The updates cover contact details, family and beneficiary changes, household and entity relationships, and account information. Every write is shown on an approval card first, and it can only reach objects your administrators have opened for writing. Where a platform is reached through the browser extension, the write runs as the advisor, in the advisor’s own session. The platform’s own permissions and audit trail therefore apply.

### Planning agents

**Available.** Tax, estate, divorce, education, marriage, family and insurance planning analyses, including tax-plan builds. These are analysis aids for a licensed professional. They do not give tax or legal advice to your clients, binding legal or tax opinions, or investment recommendations. Their output carries an in-product disclaimer and needs professional review before any of it reaches a client. Changes to tax planning are tested against reference cases before release.

### Documents Agent

**Early access.** Extracts figures from tax returns, account statements, insurance policies and estate documents, and flags items for review, such as an outdated beneficiary designation. Extracted figures are presented for review against the source document. Analysis code runs in an isolated sandbox. Uploaded and generated documents are kept under your firm’s retention settings.

### Onboarding Agent

**Early access.** Prepares account applications, ACAT and transfer forms, and beneficiary designations from records your firm already holds, including DocuSign envelopes. Nothing is submitted to a custodian or sent for signature until the user approves it on an approval card. The agent prepares paperwork; it does not decide eligibility or suitability.

### Prospect Research Agent

**Early access.** Compiles a professional profile of a prospect from public web sources and people-search services, for the advisor’s own preparation. Its output is a research draft, not a decision about anyone. The same prohibition on inferring protected characteristics applies. Your firm remains responsible for how it uses prospect information under its own privacy and marketing obligations.

### Compliance Agent

**Early access.** Helps compliance teams document suitability discussions and investment rationale from meeting records, prepare examination-ready client files, and track disclosure changes. It documents and organises. It does not make suitability determinations or replace your firm’s supervisory review, and anything it flags is for a person to assess.

### Digital Marketing Agent

**Early access.** Drafts client communications, market commentary, event invitations and LinkedIn posts in the advisor’s voice. It drafts but does not publish. No communication is sent or posted until a person at your firm has approved it, so your firm’s review of communications with the public applies as it does today.

## How your firm supervises AI output

- **Drafts until accepted.** Notes stay drafts until the advisor finalises them. Unreviewed drafts are deleted after a period your firm sets.
- **Approval before any write.** Every write to email, a CRM, DocuSign, a form or a connected platform is shown to the user on an approval card first. CRM sync works in two steps: Mili proposes and the advisor applies. Mili sends an email only after the user approves it in Mili.
- **A single, bounded path into connected platforms.** Client operations through the browser extension go through one dispatch path and are validated before they leave. Circuit breakers switch an operation off for every user after repeated failures at the platform. Individual advisors are paused automatically, and call budgets limit how much any one assistant run can do.
- **A record you can supervise.** Notes keep version history and edit history with user attribution. Finalised notes can be locked after a set period. Records can be archived and exported for supervision, including to Global Relay. Edit logs are available on request for investigations.
- **Central control.** Administrators set retention, redaction, capture modes and integration permissions for the whole organisation. Advisors cannot override them, and team administrators can adjust them only if the organisation allows it.
- **Labelling and an AI-free area.** AI-generated content is labelled as such in the product. The Scratchpad is a place for notes the advisor wants kept out of AI processing.

## Boundaries we hold our AI to

Our AI systems are not designed or configured to do the following, and their instructions direct them to decline requests to:

- make investment recommendations, including specific buy, sell or hold calls and allocation recommendations, or make suitability determinations;
- make credit, lending, underwriting, insurance or employment decisions;
- give binding legal or tax opinions;
- infer emotions, personality or protected characteristics, such as race, religion, health, sexual orientation or political views, from someone’s voice or words, or guess a speaker’s origin from their accent.

When a request falls outside these limits, the assistant declines and points the user to a qualified professional. Where context is incomplete or the audio is unclear, our models are instructed to mark the content as uncertain rather than fill the gap; we prefer omission to invention. We test these limits directly, and any failure is handled as a critical incident.

## Your data

- **No training on your data.** We do not use your data to train or improve AI models, ours or anyone else’s. We use only model providers that commit in writing not to train on what we send them. Our evaluation work uses synthetic data, or de-identified data where your agreement permits it.
- **Zero data retention at our AI providers.** Our language-model providers (OpenAI, Anthropic and Google) and speech-to-text providers (AssemblyAI and Deepgram) process your data under zero-data-retention terms, using it only to return a result. We do not use provider features that would keep your content outside those terms, such as extended prompt caching or file storage at the model provider.
- **Subprocessors.** A few services hold data because the service requires it: meeting capture, collaborative note storage, and request logging and evaluation tooling, which keep it for up to 30 days. Each is listed on our subprocessors page with what it holds and for how long. Every subprocessor is bound by a written agreement that prohibits training on your data, and we can require deletion at any time. We add a subprocessor to that page before it handles your data.
- **Personal information.** Your firm can choose categories of personal information to redact, so that they do not reach summaries, forms or connected systems. This includes card, Social Security and bank account numbers, which are redacted in the transcript before any model sees it. Social Security numbers are also masked in AI tool outputs and traces. We do not strip all personal information before every model call; other personal data reaches our model providers under the zero-retention and no-training terms above.
- **Where your data lives.** Your data is processed and stored in the United States on Amazon Web Services, and each firm’s data is logically isolated. Some of our engineering and support staff are in India. They can access your data only where necessary, with role-based permission and over encrypted connections, and that access is logged and reviewed.
- **Security.** Data is encrypted with AES-256 at rest, using AWS Key Management Service, and with TLS 1.2 or above in transit. Production access is least-privilege, exception-based, time-bound and logged, and access to AI traces and logs is restricted in the same way. Application and security logs are kept for at least 365 days.

## Records and retention

- **Your firm sets retention.** Transcripts, drafts, finalised notes, assistant conversations and documents are configured separately, from zero days to seven years or more.
- **Audio.** Audio and video recording is off by default, and transcript-only and summary-only modes are available. Where your firm enables audio capture, audio can be deleted as soon as it is transcribed. Otherwise it is deleted after 8 days by default, or after up to 30 days if your firm sets that, including copies held by our capture provider.
- **Books and records.** Extended retention is available for firms aligning with SEC Rule 17a-4, FINRA Rule 4511 or other books-and-records rules. Archiving and supervision export are supported, including to Global Relay.
- **Deletion.** Deletion workflows respect legal holds. Deleted items stay in a 7-day trash before permanent deletion. If you leave Mili, your data can be exported for 30 days and is then deleted, with backups removed on the standard backup cycle; a deletion certificate is available on request. AI traces and request logs are kept for up to 30 days.

## Connected systems

- **Nothing flows by default.** Connecting a platform starts no data exchange until your administrators enable the objects, permissions and flows. The exception is calendars: connecting a calendar syncs its events, and the Mili bot then joins meetings unless the user has chosen manual join.
- **Permissions you set.** Administrators choose which objects or folders are reachable and whether each can be read, written, both or neither. These choices are enforced everywhere, including in the assistant, not only in the interface.
- **Never broader than the source.** Each user signs in to each platform with their own identity. Access in Mili is therefore never broader than what both your firm and the source platform already allow that user.
- **Retrieval, not replication.** We do not copy whole datasets from connected platforms. We retrieve data when a feature needs it. Anything an advisor creates from that data follows your firm’s retention settings.
- **New integrations are governed changes.** Adding an integration, or giving the assistant write access to one, is a reviewed change. A new write capability also requires an impact assessment.

## Meeting capture, consent and transparency

- By default the Mili bot joins the meetings on a user’s calendar. Users can switch to joining only when they choose, and can pause capture during a meeting.
- When the Mili bot joins, participants get audible and on-screen notices. Mili supports capturing and tracking client consent, including each contact’s consent history.
- Your firm and its advisors remain responsible for obtaining consent where the law requires it, including in all-party consent states.

## How we change, test and monitor our AI

- **Change control.** Every change, including prompts and model routing, goes through a reviewed pull request, automated tests and our deployment pipeline. No individual can change production model routing, add a provider or deploy new system prompts without review, or alter AI audit logs. Configuration changes made outside the code, at our model gateway or in environment settings, are logged with their evaluation result.
- **Evaluation before release.** An offline evaluation suite runs on every assistant change and checks routing, tool use and grounding logic. Before any model change, we evaluate the proposed model against the current one, case by case, on real model output. A case that always passed and now fails blocks the release, unless the AI owner records why the regression is accepted. Quality, latency and cost are recorded for each switch, and the fairness tests below run on the proposed model before it is released.
- **Staged release and rollback.** Higher-risk features ship behind feature flags and are widened in stages. After a model release we confirm in production traces that the intended model is being called. A model change can be reversed through configuration, without a deployment. Features can be switched off with a flag, and traffic can be moved away from a failing provider to another approved provider through our model gateways.
- **Monitoring.** Production AI calls are traced and analysed daily, alongside error monitoring, circuit-breaker alerts and user feedback.
- **Vendor governance.** Before we integrate an AI provider, we require: a contractual commitment not to train on customer data; stated retention terms; SOC 2 Type II or an equivalent attestation; published model documentation; and an acceptable-use policy that prohibits discriminatory content and unauthorised profiling. Changes to providers’ terms are reviewed at the monthly management review. If a provider starts allowing training on customer data, retains it beyond our terms, or has safety or bias problems we cannot mitigate, we move traffic away from it and reassess the relationship.

## Testing for fairness

For our product, fairness means consistent accuracy and consistent treatment. A tool that is accurate for one accent and not another, or that summarises one person’s contributions differently because of who they are, is discriminatory in effect.

- **Counterfactual summaries.** We summarise the same meeting with participants’ names and genders changed, and compare the results for differences in attribution, tone and detail.
- **Prohibited-inference probes.** We ask the assistant directly for the things it must decline, such as emotion labels, protected traits, credit decisions and investment calls.
- **Transcription.** We review our transcription providers’ accuracy evidence across accents every year, and whenever a provider changes its model.
- **Cadence.** These tests repeat every quarter and before any model or vendor change, and they are a release gate for features that summarise or describe people.
- **Shared responsibility.** We have no separate content-moderation layer. We rely on our own instructions, our providers’ safety systems, human review before anything is final, and user reporting.

On request, we provide customers with a quarterly AI safety report. It covers user-reported AI issues by category, including bias, and how they were resolved; AI incidents; bias-test and evaluation results; and the uptime of each model provider.

## Incidents

An AI incident is any event involving our AI systems that affects the confidentiality, integrity or availability of data, or that could harm users, their clients or meeting participants. Examples include biased or harmful output, a prohibited inference, hallucinated content that reaches a record or a client, an agent action the advisor did not intend, prompt injection, cross-tenant exposure, and capture without the required consent.

- **Critical** (safety or bias, a serious privacy issue, or an unauthorised action in an external system): response within 1 hour during business hours, and around the clock for critical platform issues. We contain the issue by quarantining the record, switching the feature off or moving traffic to another provider, and we analyse the root cause.
- **High-impact accuracy** (for example, a major hallucination or misattribution in a client context, or wrong data written to a CRM): response within 24 hours. We correct the affected records with the advisor, add the case to our regression evaluations, and roll back the change that caused it.
- **Other quality issues:** response within 3 business days.

We notify affected firms in line with our customer agreements and data processing terms. After each critical or high incident, we run a post-incident review covering the root cause, what was affected, and the corrective actions. Its findings feed our risk register and evaluations.

## Due diligence

Our SOC 2 Type 2 report, ISO/IEC 27001 certificate and security documentation are in our [Trust Vault](https://trust.getmili.ai/). On request, customers and prospective customers can see the AI policies this notice summarises: our AI Policy, AI Governance Policy, Anti-Discrimination Policy, AI Data Retention Policy and Integration Governance framework, and our AI validation, change and incident procedures. Our [subprocessors page](/subprocessors) lists every subprocessor, and our [privacy policy](/privacy-policy) explains how we handle personal information.

## Questions or concerns

You can flag any AI output directly in the product. For questions about our AI practices, or to report a concern, email [support@getmili.ai](mailto:support@getmili.ai). For privacy questions, contact our Privacy Officer at [privacy@getmili.ai](mailto:privacy@getmili.ai).