Reference deployment · R-05
Call transcription and CRM notes for a customer-service team
Twenty-five agents writing up calls from memory between calls, badly and late. A self-hosted transcription and summarisation pipeline that drafts the CRM note, with the agent editing and saving it — and with the recording never leaving the company network.
- Source
- Designed by us against a stated scenario. 0 of 15 compliance issues are anchored in a fetched instrument.
- Evidence
- none on this page — it links to the pages that hold it
| Parameter | Declared value |
|---|---|
| Scenario | Hong Kong consumer-services company, 240 staff, contact centre of 25 agents, ~1,800 calls a week |
| Industry | Retail |
| Organisation size | 240 employees — Medium (50–249) |
| People using the system | 30 |
| Technical capability | IT team |
| Jurisdictions | Hong Kong |
| Data residency required | Hong Kong |
| Data types declared | call audio, transcripts, call notes, crm records, customer data, personal data |
| Languages | Cantonese, English, Mandarin |
| Delivery assessed | self hosted |
01Problem
Agents write the CRM note after the call, from memory, while the next call is arriving. The notes are short, inconsistent, and frequently written at the end of a shift for calls that happened hours earlier.
The cost is not the typing. It is the second contact: a customer calls back, the note says "discussed billing", and the second agent starts again. Supervisors have no reliable way to see what is actually being asked.
The team has looked at hosted transcription products. The blocker is that a recording of a customer call is personal data belonging to someone who is not an employee and cannot be asked to accept a vendor’s terms.
02Constraints
- 01Recordings and transcripts stay on company hardwarehard — eliminates optionsVoice is personal data before anything is done with it, and the data subject is a customer. Sending the audio to a third party for processing is the decision this deployment exists to avoid.
- 02The caller is told at the start of the callhard — eliminates optionsA notice covering recording and the fact that a system produces a draft summary, in the caller’s language, before the conversation starts. The notice is part of the deployment.
- 03The agent owns the notehard — eliminates optionsThe system drafts; the agent edits and saves. Nothing reaches the CRM without a person confirming it, because a wrong note about a customer becomes the truth the next agent reads.
- 04Cantonese first, with code-switchinghard — eliminates optionsMost calls are in Cantonese with English terms mixed in and some Mandarin. This is the constraint that eliminates most transcription options before any comparison begins.
- 05Retention is short and enforcedshapingAudio and transcripts expire on a schedule; the saved CRM note is what persists. The deletion job ships with the deployment.
03Recommended solution
Self-hosted transcription with diarisation, drafting into the CRM for agent approval
The language constraint is the first filter and the one most likely to be skipped. Evaluate transcription on the company’s own recordings, in Cantonese with code-switching, before anything else is decided — a word error rate measured on read English speech tells you nothing about this workload.
Diarisation matters more than it looks. A summary that cannot tell the agent from the caller produces notes that attribute the customer’s complaint to the agent, which is worse than no note.
The pipeline is deliberately boring: record, transcribe, separate speakers, summarise into the CRM’s own fields, and present it in the agent’s wrap-up screen. The value is in the last step — a draft the agent edits in ten seconds instead of composing in two minutes.
Component
Why — assessment
- 01TranscriptionWhisperX with diarisationWord-level timing and speaker separation, which is what lets a summary attribute a sentence to the right party and lets an agent jump to the moment in the recording.
- 02Transcription runtimefaster-whisperKeeps a week of calls inside a nightly window on one GPU, which is what makes self-hosting practical at this volume.
- 03SummarisationvLLM with constrained decoding to the CRM’s fieldsThe CRM expects a reason code, a resolution and a next action. Structured output means the pipeline fills fields rather than pasting a paragraph.
- 04Orchestrationn8nCall ends, audio lands, transcription runs, summary drafts, agent screen updates. A supervisor can change the flow without an engineer.
- 05Record storePostgreSQL with a retention jobTranscripts and summaries expire on schedule; the approved CRM note persists. One job, one place, one policy.
04Architecture
External data transfer
External data transfer: NONE
No edge in this design crosses the boundary drawn below. Boundary: COMPANY NETWORK.
Components
- Contact-centre agents and supervisors — people
- Call recordings from the telephony platform — storage
- Recording store (short retention) — storage
- n8n (call → transcribe → summarise → draft) — application
- PostgreSQL (transcripts, drafts, retention schedule) — database
- WhisperX + vLLM on one GPU server — inference server
- CRM (on premise) — internal system
- Speech-to-text with diarisation, plus an instruct model — model
- Company GPU server (24 GB) — hardware
Connections
- Contact-centre agents and supervisors to n8n (call → transcribe → summarise → draft) — HTTPS (confidential data)
- n8n (call → transcribe → summarise → draft) to PostgreSQL (transcripts, drafts, retention schedule) — chats, users, settings (personal data)
- n8n (call → transcribe → summarise → draft) to WhisperX + vLLM on one GPU server — prompt (confidential data)
- WhisperX + vLLM on one GPU server to Speech-to-text with diarisation, plus an instruct model — loaded weights
- Speech-to-text with diarisation, plus an instruct model to Company GPU server (24 GB) — GPU memory
- WhisperX + vLLM on one GPU server to Company GPU server (24 GB) — GPU memory
- n8n (call → transcribe → summarise → draft) to CRM (on premise) — saved call note (personal data)
External data transfer · NONE
- No edge in this design crosses out of the company network.
- Model weights are downloaded once at setup. No recording, transcript or draft leaves the company network.
- The CRM runs on the same network: it is inside the company-network boundary, and a saved note never crosses it.
- Nothing is written to the CRM until the agent has edited and saved the draft.
05Compliance
Structured issue-spotting to support your own review — not legal advice. Verify against the cited primary sources and your counsel.
15 of 27 rules fired for this scenario, across Hong Kong.
Cross Cutting
Self-hosting moves the security obligation to you
Keeping data on your own hardware answers the transfer question and creates an operations question. Patching, backups, key management, monitoring and incident response are now yours, and an unpatched inference server on the office network is a worse outcome than a well-run vendor.
- Required checks
- Name the person responsible for patching each component, and the cadence.
- Confirm backups exist, are encrypted, and have been restored at least once.
- Confirm there is an incident response path that includes this system.
- Technical controls
- Encrypt at rest and in transit, including between the application and the inference server.
- Centralise authentication through the existing identity provider rather than local accounts.
- Keep an audit log of who queried what, and protect it from the people it records.
- Subscribe to security advisories for each component and track upgrade lag.
Being able to reconstruct a decision months later
The question that arrives after a complaint is what the system was shown and what it produced on a particular day. Models change, prompts change, and indexes are rebuilt, so the answer has to be recorded at the time. Without it, the only available response is that the output cannot be reproduced.
- Required checks
- Decide what is recorded per interaction: model and version, prompt template version, retrieved document ids, output, reviewer and outcome.
- Set how long those records are kept, balanced against the retention duties that also apply to them.
- Vendor questions
- Does the vendor pin model versions, and how much notice is given before a model is retired or changed?
- Technical controls
- Version prompt templates in source control and log the version used.
- Log the model identifier and version returned by the provider, not the one you requested.
An AI deployment creates new copies of the data
Vector indexes, prompt logs, completion caches, evaluation datasets, fine-tuning checkpoints and backups are all copies of the source material in places the existing retention schedule does not mention. Deletion requests are the moment this is discovered, because deleting the source document does not delete its embedding.
- Required checks
- List every store the deployment creates and add each to the retention schedule.
- Establish how a deletion request propagates to the index, the caches and the logs.
- Establish how long backups keep material that has been deleted from the live system.
- Vendor questions
- What does the vendor retain, where, and for how long after we delete our copy?
- Technical controls
- Store the source document id with every embedding so deletion can cascade.
- Set time-to-live on prompt and completion logs rather than relying on manual cleanup.
Who can reach the model, the index and the weights
A self-hosted stack has three access surfaces that are easy to leave open: the inference endpoint, the vector index, and the weights on disk. Retrieval also carries an authorisation problem an ordinary application does not have — the index must not return a document to someone who could not open it in the source system.
- Required checks
- Confirm the inference endpoint is not reachable from outside the network and requires authentication.
- Confirm retrieval filters by the requesting user’s permissions, not only by relevance.
- Confirm who can read the model files and the index volume at the operating-system level.
- Technical controls
- Bind the inference server to a private interface and put an authenticating proxy in front of it.
- Carry document-level access control into the index and enforce it at query time.
- Encrypt the volume holding the weights and the index, and restrict it to the service account.
- Rotate API keys and keep them out of client-side code and container images.
What ends up in a prompt, and where it goes next
Even with inference inside the network, prompts and retrieved context accumulate in logs, traces and caches, and system prompts can often be extracted from the output. The leak path is internal rather than external, but it is still a copy of the source material in a new place.
- Required checks
- Write down which categories of information may be entered into a prompt, and tell people.
- Establish what the system prompt contains and whether disclosing it would matter.
- Establish which shadow tools staff are already using; the policy has to name the permitted ones.
- Vendor questions
- Are prompts and completions retained, for how long, and can retention be set to zero?
- Are prompts used for abuse monitoring, and if so who can read them and for how long?
- Technical controls
- Redact or block high-risk patterns before the prompt leaves the application.
- Keep prompt and completion logs out of general-purpose observability tools.
- Set an explicit retention period on prompt logs and enforce it.
Rights in the material you index and in what the model produces
Two separate questions get conflated. First, whether you hold the rights to index, embed or fine-tune on the material you feed the system — licensed databases, customer documents and third-party reports often say you may not. Second, whether generated output that closely reproduces protected work creates exposure. Both are contract and copyright questions that vary by jurisdiction, and neither is answered by the model licence.
- Required checks
- List the corpora going into the index and confirm each one’s terms permit machine processing and storage of derived embeddings.
- Check whether any source is a licensed third-party database with an anti-scraping or anti-derivative clause.
- Decide, and write down, who owns the output in your customer contracts.
- Vendor questions
- Does the provider offer any indemnity for third-party intellectual-property claims arising from output, and what conditions attach to it?
- Technical controls
- Record the source document for every retrieved passage so an output can be traced to what it was grounded on.
Hong Kong
DPP4 — all practicable steps to protect the data
DPP4 requires all practicable steps to protect personal data against unauthorised or accidental access, processing, erasure, loss or use, including where a data processor holds it. For a retrieval system that normally means access control that mirrors the source repository, encryption at rest and in transit, and an audit log — and it is the principle the Commissioner reaches for after a breach.
- Required checks
- Confirm retrieval cannot return a document to a user who could not open it at source.
- Confirm encryption at rest for the index, the logs and any model artefacts.
- Confirm there is a tested route to detect and respond to unauthorised access.
- Vendor questions
- What security certifications do you hold, and can we see the current report rather than a badge?
- Which of your staff can access customer content, and under what controls?
- Technical controls
- Enforce document-level permissions at query time, not only at ingestion time.
- Authenticate through the existing identity provider rather than local accounts.
- Keep an access log covering who queried what, retained separately from the application.
DPP3 — a new purpose needs express and voluntary consent
DPP3 prohibits using personal data for a new purpose that is not, or is unrelated to, the purpose for which it was collected, unless the data subject gives express and voluntary consent. This is the provision that decides whether existing client and staff records can be used to power an assistant at all, and it is answered by reading what people were told at collection.
- Required checks
- Retrieve the personal information collection statements actually used for the data in scope.
- Assess whether the AI use is the original purpose, a directly related purpose, or a new one.
- Where it is a new purpose, plan how express consent is obtained — or narrow the corpus.
- Technical controls
- Tag indexed documents with the collection basis so an out-of-scope source is visible.
Human review required — take this to your counsel
PCPD Model Framework — AI governance and the level of human oversight
The PCPD’s Artificial Intelligence: Model Personal Data Protection Framework recommends that organisations formulate policies, practices and procedures when they procure, implement and use AI solutions, taking into account its recommended measures in AI strategy and governance, risk assessment and human oversight, customisation of AI models and implementation and management of AI systems, and communication and engagement with stakeholders. It is guidance rather than law.
- Required checks
- Decide who owns AI governance internally and what they sign off before a system goes live.
- Run a risk assessment that sets the level of human oversight for this system, and record it.
- Train the people who will use the system, and record that you did.
- Vendor questions
- What documentation do you provide to support a customer’s own AI risk assessment?
- Technical controls
- Give reviewers the retrieved sources alongside the output so oversight is possible in practice.
DPP1 — collection must be lawful, necessary and not excessive
DPP1 allows personal data to be collected only for a lawful purpose directly related to a function or activity of the data user, and requires the data collected to be necessary and adequate but not excessive for that purpose. Indexing a whole document store for an assistant is a collection decision made at scale, and "we indexed everything because it was easier" is the shape of an excessive-collection finding.
- Required checks
- State the purpose the AI system serves, in the terms the business would defend it in.
- List which repositories are indexed and confirm each is necessary for that purpose.
- Check whether the personal information collection statement given to staff and clients covers this use.
- Technical controls
- Scope the index by folder, label or classification rather than by whole drive.
- Exclude repositories that exist for a different purpose, such as HR files, unless they are in scope deliberately.
PCPD checklist — write the internal generative AI policy
The PCPD’s 2025 checklist is explicit about what an internal policy should cover: which generative AI tools are permitted, the permissible purposes, clear instructions on the types and amounts of information that can be inputted into the Gen AI tools, lawful and ethical use and bias, which devices and which categories of employee may use the tools, AI incident reporting, and the consequences of a violation.
- Required checks
- Name the permitted tools, including whether publicly available tools are allowed at all.
- Say which categories of employee may use them, on which devices.
- Give concrete instructions on what may go into a prompt, with examples rather than principles.
- Add AI incidents to the existing incident response plan and say what an AI incident is.
- Technical controls
- Make the sanctioned tool easier to reach than the unsanctioned one; policy alone does not move behaviour.
DPP2 — accuracy, and no longer than necessary
DPP2 requires all practicable steps to keep personal data accurate and not to keep it longer than is necessary for the purpose it is used for. Where a data processor is engaged, the data user must adopt contractual or other means to ensure the processor complies with the same retention requirement. An AI deployment multiplies the copies: embeddings, prompt logs, cached completions and evaluation sets all fall inside this.
- Required checks
- Add every store the deployment creates to the retention schedule with a stated period.
- Confirm the contract with any processor caps their retention and that you can verify it.
- Decide what "accurate" means for a generated answer, and how a wrong one is corrected at source.
- Vendor questions
- How long do you retain prompts, outputs and logs, and can that be reduced contractually?
- Technical controls
- Set a time-to-live on prompt and completion logs.
- Re-index on a schedule so the assistant does not answer from a superseded document.
DPP6 — access and correction, and the log book
DPP6 gives data subjects the right to request access to and correction of their own personal data, with detailed provisions in Part 5 of the Ordinance on manner and timeframe, on when a request may be refused, and on maintaining a log book recording every refusal. A vector index and a prompt log are places that data now lives, and a data access request reaches them.
- Required checks
- Establish how a data access request is answered when the data also sits in an index or a log.
- Establish how a correction propagates from the source document to the index.
- Confirm the refusal log book exists and covers requests touching the AI system.
- Vendor questions
- How do we extract or delete a specific individual’s data from your service, and how long does it take?
- Technical controls
- Keep the source document id on every embedding so a subject can be located across stores.
DPP5 — openness about policies, practices and what you hold
DPP5 requires all practicable steps to make a data user’s personal data policies and practices open, along with the kind of personal data held and the main purposes for holding it. Deploying an assistant over personal data changes the practices, so the published statement has to change with it.
- Required checks
- Update the privacy policy and internal data handling notice to describe the AI processing.
- Say plainly, where people will see it, that an AI system is involved and what it does.
Data stays inside — but the weights still came from outside
Keeping documents on your own server removes the transfer question for the content. It does not remove the supply chain: model weights, container images and dependencies are downloaded from third parties, and a gated repository records who downloaded what and when. That is a procurement and integrity matter rather than a personal data transfer, and it is worth stating explicitly so nobody assumes the system is hermetic.
- Required checks
- Record which model revision you downloaded, from where, and under which licence.
- Note that accepting gated access terms is a contract, and check who accepted it.
- Technical controls
- Verify checksums on downloaded weights and pin the revision rather than tracking a moving tag.
- Mirror the artefacts internally so a rebuild does not depend on the upstream still being there.
Structured issue-spotting to support your own review — not legal advice. Verify against the cited primary sources and your counsel.
What this reading does not know
- Whether any of the data falls into a special or sensitive category.
- Whether the documents are confidential to clients or counterparties.
- Whether any material is covered by legal professional privilege.
06Cost range
| Line | One-off |
|---|---|
| Software | HK$0 |
| Model | HK$0 |
| Infrastructure | HK$31,000 – HK$71,000 |
| Implementation | HK$54,000 – HK$300,000 |
| Total | HK$85,000 – HK$370,000 |
| From year two | HK$75,000 – HK$380,000 a year |
Assumptions
- Software: nil. Every component in this recipe is open source and self-installed, so there is no licence fee. Check each licence for use limits before relying on that (see the recipe's open-source-licensing compliance note).
- Model: nil per month. Open weights are downloaded once and served on your own hardware, so there is no per-token charge; the cost of running them sits in infrastructure.
- Infrastructure: On-premise single 24 GB GPU server, a one-off purchase of 4000–9000 USD (indicative build cost for the complete machine, USD, Aug 2026 — verify with a local supplier). Typically written down over three to five years.
- The purchase price excludes electricity, cooling, UPS, rack space, offsite backup and hardware support cover; those are bracketed in the from-year-two line instead of being left as an unpriced list.
- Implementation: 9–20 FDE-days at 6000–15000 HKD per day. One-off. Covers installation, configuration, ingestion of an initial corpus, an evaluation pass and handover; excludes ongoing support and internal staff time.
- Infrastructure converted from USD using HKMA Linked Exchange Rate System: HK$7.75–7.85 to one US dollar.
- Basis: one-off only — implementation and the hardware purchase. This recommendation has no recurring monthly line at all, so the total is what it costs to stand up, not a monthly bill. What it costs to keep running is the from-year-two line below.
- Sized for 30 users. Every figure is an assessment from the inputs listed above, not a quotation.
- From year two this costs roughly HKD 75,000–HKD 380,000 a year to keep running. That is an order of magnitude for a budget conversation, not a quotation: every line below is derived from the hardware price and the FDE day rate already shown, and no supplier was asked.
- From year two — running the hardware: HKD 3,100–HKD 18,000 a year, taken as 10–25% of the HKD 31,000–HKD 71,000 purchase price and covering electricity, cooling or rack space, offsite backup and hardware support cover together. That percentage band is our own bracket, not a supplier quote — no price was fetched for any of those four items. Replace it with your electricity tariff, rack charge and a support quote.
- From year two — ongoing time: 12–24 FDE-days a year (one to two days a month, the figure the recipe's own cost model uses for support and patching) at HKD 6,000–HKD 15,000 per day = HKD 72,000–HKD 360,000. Model updates, index rebuilds, OS and driver patching, and onboarding questions. Internal staff time costs the same hours whether or not it is invoiced.
- Rounding: every figure above is rounded to two significant figures, because each is an indicative band rather than a quotation. The rounded lines may therefore not add up exactly to the rounded total.
Produced by the same cost model an answer uses, from the declared user count, the hardware profile and the implementation band below. Every figure is a range rounded to two significant figures, and the assumptions above are the model’s own.
07Difficulty
4 / 5
Multiple weeks and a team that has shipped infrastructure
- AssessmentStarting point 2/5: software you install, run and keep running on your own machines.
- Assessment+0.5 You run the model server yourself: GPU drivers, quantisation choice, memory headroom and restarts are all yours to own.
- Assessment+0.5 Connectors into existing systems bring credentials, permission mapping, pagination and incremental sync — usually the part that takes longest.
- Assessment+0.5 Scans or audio have to be converted before a model sees them, and the conversion quality sets the ceiling on everything downstream.
- Assessment+0.5 A multi-step workflow needs branches, retries, an exception queue and someone who owns it when it stalls.
- Assessment+0.5 Contract review, consent, retention rules and a vendor assessment are project work that happens alongside the build, not after it.
- Assessment-0.5 An in-house IT team can run the server, the backups and the identity provider already.
- AssessmentAssessed difficulty 4/5 (2 +0.5 +0.5 +0.5 +0.5 +0.5 -0.5 = 4, rounded and capped to 1–5).
08Implementation path
This reference implements the Meeting and call transcription to CRM notes recipe, which carries the components, the ordered steps, the commands and the evidence behind each one.
- Implementation
- 9–20 FDE-days
- Use case
- CRM call summaries
AssessmentAbove the recipe’s 6–15 day band: a Cantonese transcription evaluation on the company’s own recordings, the telephony integration and the retention job are all additions to the base recipe.
This reference would not suit
- A team whose calls are already summarised well by the telephony vendor under terms the company accepts. The constraint that drives this design is the recording leaving the network; without it, buy.
- Under roughly 300 calls a week. The pipeline is worth building when the wrap-up time saved exceeds the attention the deployment needs.
- Any team wanting agent performance scoring from the transcripts. That is monitoring of employees, with a different set of obligations, and it should be scoped and consulted on separately rather than added to this.
09Evidence
No evidence record for this design could be resolved when this page was rendered. The documents it rests on are named on the recipe page; the compliance statements above are shown as assessments rather than facts because of it.
7 of 7 declared references had no stored evidence record at render time and are not listed above.
10Hire or build — next step
If your situation resembles the scenario at the top of this page, the next step is either to build it from the recipe or to describe your own constraints and have them read against the rules rather than against this one.