Skip to content
Is there an AI for this?

Use case

Department assistant

An assistant scoped to one team — sales, HR, finance, legal — over that team’s own documents and systems. Narrower than a company-wide assistant, and easier to get right, because one department can say what a good answer looks like.

Source
Editorial ontology entry — no fetched document behind this page
Evidence
none on this page — it links to the pages that hold it
Category
Knowledge and search
Typical risk
high
Entry
editorial · reviewed 27 Aug 2026

01What this is

A department assistant serves a single function: it reads that department's handbook, contracts, tickets or ledgers, answers questions over them, and drafts the documents that team writes all day. The technology is the same retrieval-plus-model stack as company-wide search; what differs is that the corpus is bounded, the audience is known, and there is somebody who can judge whether an answer was right.

A good deployment starts from the department's own permission model rather than a copy of it, because a finance assistant that can see the whole shared drive is a data-access change disguised as an AI project. Scope the index to the systems that team already uses, agree a short list of questions it must answer well, and measure against those before anyone else is invited in. Rolling out department by department also gives each function its own retention and disclosure settings, which a single company-wide deployment rarely gets right for everyone.

Pitfalls: an HR assistant indexed over files containing employee personal data with no lawful basis recorded for the new processing; a finance assistant treated as authoritative on figures it retrieved but did not compute; and a "sales assistant" that is really a company-wide assistant with a different name and therefore the whole company's exposure. Where the department handles special-category or privileged material, the boundary is a compliance control, not a product decision.

Typical data
internal documents, employee data, crm records, financial records, client documents
Solution classes it admits
Enterprise SaaS, Model API, Private cloud, Self-hosted

02Deployment options

  • ASSESSMENT

    On a neutral reading of this use case, Private cloud is recommended, Self-hosted is a strong alternative, Model API is a strong alternative and Enterprise SaaS is conditional.

  • ASSESSMENT

    Read as a generic reading of this page, not a recommendation: no organisation, size, jurisdiction, budget or technical capability has been supplied, so wherever an option depends on one of those, it says "unknown". Ask your own question to get a verdict that accounts for them.

Private cloud

RECOMMENDED

Managed model API or private model deployment in your cloud account

  • ASSESSMENT

    Two patterns fit inside one account in a region you name: call a managed foundation-model API such as Amazon Bedrock, Microsoft Foundry / Azure OpenAI, or Vertex AI; or deploy an open-weight model on GPU compute you control. Your application, retrieval layer, storage, identity and logs remain in your cloud boundary in both patterns.

  • ASSESSMENT

    The managed-API pattern can use closed-source frontier models without buying or operating GPUs. It is usually the fastest way to build a custom workflow, but prompts and retrieved context are processed by the managed service, so model availability, retention, abuse monitoring and regional routing must be checked for the exact feature and endpoint.

  • ASSESSMENT

    The private-model pattern gives more control over weights, serving and network paths, and can use managed endpoints or your own containers. It also makes your team responsible for capacity, patches, model upgrades, evaluation and failover.

  • ASSESSMENT

    Which account you already have is a real input, not a detail: no existing cloud account was named. An organisation that already has a landing zone, an identity provider and a signed agreement with one provider is buying a feature; one that does not is buying a cloud programme, and those are different projects.

  • ASSESSMENT

    The cloud provider becomes a data processor in either pattern: you need a DPA, a documented region, and an answer on cross-region routing and where support staff can access the environment from.

  • RECOMMENDATION

    Start with the managed-API pattern when the workflow is custom but model operations are not the source of competitive advantage; move to private model serving only if evaluation, volume, portability or the data boundary justifies the extra operations. Your stated technical capability is "unknown".

  • RECOMMENDATION

    Recommended for this brief: one tenancy in a region you name is the smallest boundary that still gives you a frontier model, and opening an account is less work than building a server room, given stated technical capability "unknown", the brief involves confidential documents and personal data, no existing cloud account was named, and you did not ask for local processing.

Model API

STRONG ALTERNATIVE

A model vendor’s API behind an application you build and own

  • ASSESSMENT

    You write and host the application — the interface, the retrieval layer, the database, the access control, the audit log — and call somebody else’s endpoint for the model itself. Two kinds of endpoint sit in this class: a closed model from the vendor that made it (OpenAI, Anthropic, Google Gemini, xAI, DeepSeek, Moonshot, Mistral, Cohere), and an open-weight model served by a managed inference provider (Together, Fireworks, Groq and others).

  • ASSESSMENT

    Those two are not interchangeable. A closed model can only be obtained from its vendor or from a cloud that licenses it, so the model and the supplier are one decision. An open-weight model can be moved: the same weights run on a managed endpoint today and on your own GPU later, which makes the provider a swappable component rather than a dependency — and makes the licence, not the contract, the document that governs what you may do with it.

  • ASSESSMENT

    It is the shortest path to a frontier model: no GPUs to buy, no capacity to plan, no serving stack to patch, and you can change model with a configuration line. What it costs instead is a per-token bill that scales with use and a dependency on one supplier’s availability, pricing and deprecation schedule.

  • ASSESSMENT

    What the supplier sees is the whole prompt: the user's question, the system instructions, and every passage your retrieval layer attached to it — which is usually the most sensitive part, because retrieval is what puts internal documents into the request. For a brief that involves confidential documents and personal data, that is the attribute to check first. What stays yours is everything else: the application, the retrieval index, the identity system, the logs, and the record of who asked what.

  • ASSESSMENT

    Nothing about a supplier's handling of your data is assumed here. Before real content goes near an endpoint, verify against that supplier's own documents: the data processing agreement, and that it covers the API rather than only the consumer product; whether zero-data-retention or an equivalent no-logging mode is available on your account, and on which endpoints; the default retention period for prompts and outputs, and what triggers human review; the region the request is served from, and whether that is a commitment or a routing preference; the current subprocessor list and how you are notified when it changes; the supported-countries page, which decides whether you may use the service at all.

  • RECOMMENDATION

    Take this route when the workflow is yours but the model is not the differentiator, and your team can build and run an application. Your stated technical capability is "unknown", which is the attribute this option most depends on. Where the same model is available inside your own cloud account, compare it against private cloud before committing — the application is identical and only the tenancy of the model changes.

  • RECOMMENDATION

    A strong alternative for this brief: one tenancy in a region you name is the smallest boundary that still gives you a frontier model, and opening an account is less work than building a server room, given stated technical capability "unknown", the brief involves confidential documents and personal data, no existing cloud account was named, and you did not ask for local processing.

Self-hosted

STRONG ALTERNATIVE

Open-weight models on infrastructure you operate

  • ASSESSMENT

    Documents, queries and embeddings stay on machines you own, using an open-weight model whose licence you review. For a brief that involves confidential documents and personal data, that removes a model-API vendor from the data path rather than governing that transfer by contract.

  • ASSESSMENT

    It costs you the operational work instead: a GPU server, Docker, Linux, backups and a patching routine. Your stated technical capability is "unknown", which is the attribute this option most depends on.

  • ASSESSMENT

    No processor agreement, subprocessor list or cross-border transfer assessment is needed for the model itself, because no third party processes the content.

  • RECOMMENDATION

    Recommended where local processing is preferred (you did not say so) and the content is sensitive (confidential documents and personal data).

  • RECOMMENDATION

    A strong alternative for this brief: one tenancy in a region you name is the smallest boundary that still gives you a frontier model, and opening an account is less work than building a server room, given stated technical capability "unknown", the brief involves confidential documents and personal data, no existing cloud account was named, and you did not ask for local processing.

Enterprise SaaS

CONSIDER IF

Finished closed-source cloud product with enterprise controls

  • ASSESSMENT

    This is a complete vendor application, not a model API: examples include an enterprise assistant, coding copilot or document product with the workflow, interface, connectors and administration already built. It can use closed-source cloud models while requiring no model hosting or application engineering from your team.

  • RECOMMENDATION

    Choose it when the product already performs the actual workflow and its controls meet your requirements. Do not choose it only because its underlying model is strong: a finished SaaS product is less flexible than building against a managed API when your process, integrations or review steps are organisation-specific.

  • ASSESSMENT

    Vendor commitments are treated as unverified until we have fetched the page that makes them. Until then this option carries questions to ask, not assurances: a signed data processing agreement covering the data you will actually put in; a documented data residency commitment naming the region, in the contract rather than a blog post; a written no-training commitment for your content, including uploads and connected sources; stated retention periods and a deletion path you can exercise; an administrative audit log you can export, and SSO with group-based access control.

  • RECOMMENDATION

    No jurisdiction was named, so this is the check rather than the conclusion: compare the vendor's stated processing locations and subprocessor list against the cross-border transfer rules wherever you operate before uploading anything.

  • RECOMMENDATION

    Worth considering for this brief: one tenancy in a region you name is the smallest boundary that still gives you a frontier model, and opening an account is less work than building a server room, given stated technical capability "unknown", the brief involves confidential documents and personal data, no existing cloud account was named, and you did not ask for local processing.


03Deployment stacks

0 published

No deployment stack has been written up for this use case yet.


04Tools by hosting option

7 tools

Self-hosted1

Private cloud5

Vendor cloud7


05Compliance hot spots

This use case usually raises personal data, confidentiality, model access, retention, logging, transparency, professional secrecy.

Personal data
No published jurisdiction page names this topic yet
Confidentiality
No published jurisdiction page names this topic yet
Model access
No published jurisdiction page names this topic yet
Retention
No published jurisdiction page names this topic yet
Logging
No published jurisdiction page names this topic yet
Transparency
No published jurisdiction page names this topic yet
Professional secrecy
No published jurisdiction page names this topic yet

06Example questions


Improve this page

Sign in to contribute

From the field

0 deployments · 0 questions

Nobody has reported deploying this here yet, and no question has been opened against this page. Both appear once a reviewer accepts them.