Reference deployment · R-02
AI-assisted candidate workflow for a European HR team
An in-house recruiting team drowning in applications, in a jurisdiction where filtering candidates by machine is a regulated activity. A single-region private-cloud deployment that summarises and cross-references, never ranks or rejects, with the oversight obligations written into the design.
- Source
- Designed by us against a stated scenario. 0 of 28 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 | European manufacturer, ~900 employees, in-house recruiting team of 6, German operations with a works council |
| Industry | Recruitment and HR |
| Organisation size | 900 employees — Large (250–999) |
| People using the system | 12 |
| Technical capability | IT team |
| Jurisdictions | European Union |
| Data residency required | EEA |
| Data types declared | candidate data, personal data, internal documents, forms |
| Languages | German, English |
| Delivery assessed | private cloud |
01Problem
The recruiting team receives roughly 400 applications a month across 30 open roles. Most of the reviewing time goes on reading CVs that were written for a different role, and on re-reading the same candidate’s material when they apply again six months later.
The team has asked for "AI screening". What they have described when watched is not screening: it is summarising a CV against a role description, surfacing that this candidate applied before, and pulling the relevant paragraph out of a twelve-page attachment.
That distinction is the whole deployment. One of those is a regulated activity with obligations attached; the other is a reading aid.
02Constraints
- 01No automated rejection, ranking or scoring of candidateshard — eliminates optionsThe system summarises and retrieves. It does not order candidates, does not produce a score, and does not filter anyone out of the process. A recruiter reads every application that reaches the stage they would have reached anyway.
- 02Candidate data stays in the EEAhard — eliminates optionsProcessing and storage both, including the inference endpoint — not only the database. A fallback region outside the EEA is a transfer, whether or not it is ever used.
- 03The works council is consulted before deployment, not afterhard — eliminates optionsA system that processes employee-facing data in German operations engages co-determination rights over technical monitoring equipment. Deploying first is how a pilot becomes a dispute.
- 04Retention follows the existing recruiting policyhard — eliminates optionsSummaries and embeddings are derived personal data and expire with the application they came from. The deletion job is part of the deployment, not a later addition.
- 05German and English in the same corpusshapingCVs and role descriptions arrive in both, often mixed. The model and the embedding both need to work across the pair.
03Recommended solution
Private-cloud retrieval in one EEA region, scoped to summarise rather than decide
The first constraint is a design constraint, not a policy one. A system that cannot rank has no ranking code, no score field and no ordering in the interface — because a scoring field that exists "but is not used" is used within a quarter.
The residency constraint chooses private cloud over self-hosted: the volume does not justify a GPU purchase, and a single-tenant deployment in one EEA region gives the same boundary at rented cost. The region is pinned and the fallback is disabled rather than left at the provider default.
The oversight constraint is met by naming the recruiter as the decision-maker in the design and by keeping every summary next to the document it came from. A summary a recruiter cannot check against the source is a system output being trusted, which is the failure mode the whole design is arranged to avoid.
Component
Why — assessment
- 01InterfaceOpen WebUI, with the candidate record as the workspaceThe recruiter works from a document set, not a chat history. Scoping the workspace to one application keeps retrieval from crossing candidates.
- 02IdentityThe company’s OIDC provider, recruiting group onlyAccess to candidate material is already governed. This deployment inherits that rather than defining a second list.
- 03IngestionDoclingCVs arrive as PDF and Office files with layout that carries meaning; structure-preserving extraction is what keeps a two-column CV readable.
- 04Vector storePostgreSQL with pgvector, in-regionEmbeddings of candidate material are personal data. Keeping them in the same database as the records they derive from means one retention job deletes both.
- 05InferencevLLM on a rented single-tenant GPU instance, region pinnedKeeps the inference endpoint inside the residency boundary, which a managed multi-region API does not.
- 06Audit logAppend-only record of every summary generatedWho asked, about which candidate, and what came back. The works council will ask, and a deployment that cannot answer will be switched off.
04Architecture
External data transfer
External data transfer: SOME
Some company data crosses the boundary drawn below. Boundary: COMPANY NETWORK, PRIVATE CLOUD · Private cloud — One EEA region, REGION · One EEA region.
Components
- Recruiting team (12) — people
- Document ingestion (Docling) — storage
- Private ingress (TLS, company VPN) — network
- Open WebUI (workspace per application) — application
- Company OIDC provider (recruiting group) — identity
- Retrieval layer (scoped to one candidate) — retrieval
- PostgreSQL + pgvector (embeddings, in-region) — vector store
- PostgreSQL (sessions, audit log) — database
- Application files (object storage, in-region) — storage
- vLLM on a single-tenant GPU instance — inference server
- Open-weights instruct model, German and English — model
- Rented GPU instance (region pinned) — hardware
Connections
- Recruiting team (12) to Private ingress (TLS, company VPN) — HTTPS (confidential data)
- Private ingress (TLS, company VPN) to Open WebUI (workspace per application) — reverse proxy (confidential data)
- Open WebUI (workspace per application) to Company OIDC provider (recruiting group) — OIDC sign-in (personal data)
- Document ingestion (Docling) to Retrieval layer (scoped to one candidate) — documents to index (confidential data)
- Open WebUI (workspace per application) to Retrieval layer (scoped to one candidate) — question + user groups (confidential data)
- Retrieval layer (scoped to one candidate) to PostgreSQL + pgvector (embeddings, in-region) — embedding search (confidential data)
- Retrieval layer (scoped to one candidate) to PostgreSQL (sessions, audit log) — documents + permissions (confidential data)
- Open WebUI (workspace per application) to PostgreSQL (sessions, audit log) — chats, users, settings (personal data)
- Retrieval layer (scoped to one candidate) to Application files (object storage, in-region) — original files (confidential data)
- Retrieval layer (scoped to one candidate) to vLLM on a single-tenant GPU instance — prompt + retrieved passages (confidential data)
- vLLM on a single-tenant GPU instance to Open-weights instruct model, German and English — loaded weights
- Open-weights instruct model, German and English to Rented GPU instance (region pinned) — GPU memory
- vLLM on a single-tenant GPU instance to Rented GPU instance (region pinned) — GPU memory
External data transfer · SOME
- confidential content leaves your premises for your own cloud tenancy ("Private ingress (TLS, company VPN)"). You keep control of the account; the provider is a processor, so a DPA and a documented region apply.
- The cloud provider is a processor for everything inside the boundary, so the agreement, the sub-processor list and the notice terms are part of this deployment rather than a procurement footnote.
- Cross-region failover is disabled deliberately: an automatic fallback to a region outside the EEA is a transfer that happens without anybody deciding to make it.
05Compliance
Structured issue-spotting to support your own review — not legal advice. Verify against the cited primary sources and your counsel.
28 of 33 rules fired for this scenario, across European Union.
Cross Cutting
Confidentiality duties bind independently of data protection law
Material can be entirely free of personal data and still be the material a contract stops you disclosing. Client retainers, non-disclosure agreements, supplier contracts and common-law duties are the usual sources, and several of them require consent before a third party processes the material at all — which a model API call is.
- Required checks
- Review the confidentiality clauses in the contracts covering the material going into the system.
- Identify any contract requiring notice or consent before a subcontractor processes the material.
- Decide whether the deployment needs a confidentiality carve-out negotiated into new contracts.
- Vendor questions
- Will the vendor accept a confidentiality undertaking beyond its standard terms?
- Which staff at the vendor can access customer content, under what controls?
- Technical controls
- Segregate the most sensitive corpora into an index that the general assistant cannot reach.
Human review required — take this to your counsel
What ends up in a prompt, and where it goes next
Every prompt is a transfer of whatever it contains. Staff paste more than they intend, retrieved context travels with the prompt, and system prompts can often be extracted from the output. Assume anything reaching the model has left your control unless the contract and the architecture say otherwise.
- 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.
The acceptable-use policy may exclude your use case
Acceptable-use policies commonly carve out unsupervised legal, medical and financial advice, decisions about people without human review, and some surveillance and biometric uses. They are incorporated into the contract by reference and change without a signature, so the version that matters is the one live on the day you rely on it.
- Required checks
- Read the acceptable-use policy against your actual use case, not against a summary of it.
- Where a carve-out applies, decide whether human review brings the use back inside the policy.
- Set a reminder to re-read the policy — it changes without notice to you.
- Vendor questions
- Does your acceptable-use policy permit this use case, and will you confirm that in writing?
- How are we notified when the acceptable-use policy changes?
Human review required — take this to your counsel
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.
A residency requirement was stated but not yet matched to the vendor
The brief requires data to stay in EEA, and we have no verified statement of where this vendor processes and stores it. Residency has at least four separate answers — where data is stored, where inference runs, where logs are retained, and where support staff sit — and a vendor can satisfy one and not the others.
- Required checks
- Get the residency commitment in the contract, covering storage, inference, logging and support access.
- Check whether the region has to be selected explicitly; a regional endpoint is rarely the default.
- Check what happens on failover — a disaster-recovery region in another country defeats the commitment.
- Vendor questions
- In which region is data stored at rest, and in which region does inference run?
- Where are logs, backups and support tooling located, and which staff outside the region can access content?
- What is the failover region, and does the residency commitment survive a failover?
- Technical controls
- Pin the regional endpoint in configuration and alert if traffic is served from elsewhere.
Vendor documentation has not been verified
We could not verify a data processing agreement, a subprocessor list and a stated processing region for this vendor from a retrieved document. That is a gap in our evidence, not a finding against the vendor: until a document has been fetched and read, nothing here should be treated as settled either way.
- Required checks
- Obtain the current versions of the processing agreement, subprocessor list, security page and any regional-processing commitment.
- Check that what the sales conversation promised also appears in the contract.
- Vendor questions
- Where is your data processing agreement published, and which version applies to us?
- Where is your subprocessor list, and how much notice do we get before it changes?
- Do you train on customer content by default, and where is that stated contractually?
- In which country or region is inference performed, and where are logs retained?
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.
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.
The vendor’s terms may not permit the deployment you are planning
Provider terms routinely restrict things architectures assume: sharing seats, building a competing service, benchmarking and publishing results, reselling capacity, and processing certain data categories. A consumer or self-serve plan often carries different terms from the enterprise agreement, and the enterprise agreement is the one worth reading.
- Required checks
- Identify which contract actually governs — self-serve terms, an order form, or a negotiated agreement.
- Check restrictions on seat sharing and on service accounts, which a shared internal assistant can breach without anyone noticing.
- Check whether the terms allow the categories of data you intend to send.
- Vendor questions
- Which agreement governs our use, and can we have the current version in writing?
- Are there restrictions on the data categories or the industries we may use the service for?
European Union
Article 35 — a data protection impact assessment is likely required
Where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons, the controller must carry out an impact assessment before the processing. Systematic evaluation of people, large-scale special category processing and systematic monitoring of a publicly accessible area on a large scale each point that way, and an AI deployment over employee or customer data usually touches at least one.
- Required checks
- Run the assessment before deployment, not after, and keep it as a living document.
- Include the residual risk and the decision to accept it, signed by someone who can accept it.
- Check the national supervisory authority’s list of processing that always requires an assessment.
- Vendor questions
- Will you provide the technical information we need to complete an impact assessment?
Human review required — take this to your counsel
Article 22 — decisions based solely on automated processing
Article 22 gives a data subject the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects or similarly significantly affects them. Where the contract or consent exception applies, the controller must implement suitable measures to safeguard the data subject’s rights including at least the right to obtain human intervention, to express a point of view and to contest the decision. Automated shortlisting is the archetype.
- Required checks
- Decide whether the decision is "solely" automated, and be honest about whether the human step is real.
- If it is, identify which Article 22(2) exception applies.
- Build the contest route: who hears it, on what information, and within what time.
- Vendor questions
- Does the product support a human review step that shows the reviewer why the output was produced?
- Technical controls
- Record every decision with its inputs, so a contest can be answered with facts.
- Make the override path a first-class feature rather than an out-of-band email.
Human review required — take this to your counsel
Germany — BDSG § 26 and the limits of consent at work
BDSG § 26 permits processing employee data where it is necessary for a decision about entering into, performing or ending the employment relationship. Consent in an employment context is subject to conditions because of the dependency in the relationship, collective agreements are an available basis, and § 26(6) expressly preserves the participation rights of employee representatives.
- Required checks
- Decide whether necessity or a collective agreement is the basis; do not default to consent.
- Where a works agreement is the route, start it early — it takes longer than the build.
- Confirm what happens to employees who decline, if consent is used at all.
Human review required — take this to your counsel
Chapter V — the transfer is often the inference call
Transfers of personal data to a third country need an Article 45 adequacy decision, Article 46 appropriate safeguards, or a derogation. In an AI deployment the transfer is easy to miss because it is not the storage contract: it is the model API call, the log pipeline and the support tunnel, and those three can end up in three different countries.
- Required checks
- Identify every hop where personal data leaves the EEA, including logging and support access.
- For each, identify the Article 45 or 46 route relied on.
- Complete a transfer impact assessment where safeguards rather than adequacy are relied on.
- Vendor questions
- Where is inference performed, and can it be pinned to an EEA region contractually?
- Which of your staff outside the EEA can access customer content, and under what controls?
- Technical controls
- Pin regional endpoints in configuration and alert on traffic served from elsewhere.
Human review required — take this to your counsel
Article 28 — the processor contract and the guarantees behind it
A controller may use only processors providing sufficient guarantees to implement appropriate technical and organisational measures. The contract must be in writing, including in electronic form, and must contain the Article 28(3) terms, including that the processor acts only on documented instructions. A published security page is not a guarantee; a contract is.
- Required checks
- Obtain the processing agreement and check it against the Article 28(3) list, term by term.
- Confirm the documented instructions actually describe what you want done.
- Check the audit and assistance provisions are usable rather than theoretical.
- Vendor questions
- Which entity is the processor, and does the agreement cover the model provider behind you?
- How do you support us in responding to data subject requests?
Annex III point 4 — employment and worker management is a high-risk class
Annex III point 4 covers AI intended to be used for the recruitment or selection of natural persons — including placing targeted job advertisements, analysing and filtering applications, and evaluating candidates — and for decisions on terms of work, promotion, termination, task allocation and performance monitoring. The high-risk obligations in Chapter III Sections 1 to 3 apply from 2 December 2027, moved from 2 August 2026 by Regulation (EU) 2026/1744. The Annex III text itself did not change.
- Required checks
- Confirm whether the intended use falls in Annex III point 4, and record the reasoning either way.
- Identify whether you are a provider or a deployer; buying a tool usually makes you a deployer, but rebranding or materially modifying it can make you a provider.
- Plan against the 2 December 2027 date rather than treating the deferral as a reprieve — a system procured now will still be running then.
- Vendor questions
- Will you classify this system under the AI Act, and will you provide the instructions for use a deployer needs?
- What is your timeline for conformity assessment and the EU declaration of conformity?
- Technical controls
- Build automatic logging now: the deployer obligations include keeping logs, and retrofitting them is expensive.
Human review required — take this to your counsel
Deployer duties: oversight by people with competence and authority
For high-risk systems the AI Act puts duties on the deployer as well as the provider: use the system according to the instructions for use, assign human oversight to people with the necessary competence, training and authority, ensure input data is relevant and sufficiently representative, and inform workers and their representatives before putting the system into use. These apply from 2 December 2027 for Annex III systems.
- Required checks
- Name the people who will exercise oversight and confirm they have authority to override.
- Confirm the input data you will feed the system is relevant to its intended purpose.
- Plan the notification to workers and their representatives.
- Vendor questions
- Can we see the instructions for use, including the stated limitations and the expected oversight measures?
- Technical controls
- Surface the system’s confidence and the basis for an output so oversight is informed.
Human review required — take this to your counsel
Germany — works council co-determination and the duty to inform
BetrVG § 87(1) no. 6 gives the works council co-determination over the introduction and use of technical devices designed to monitor the behaviour or performance of employees. BetrVG § 90 separately requires the employer to inform the works council in good time about planning of working procedures and workflows including the use of artificial intelligence, and to consult early enough for its concerns to be taken into account.
- Required checks
- Establish whether a works council exists at the affected sites, and engage it during design rather than after.
- Prepare the information § 90 requires, with the documents, before the planning is settled.
- Budget time for a works agreement covering logging, evaluation and the limits on use.
- Vendor questions
- Can logging and analytics be configured down to what a works agreement permits, and demonstrated?
- Technical controls
- Make per-user analytics switchable, so the technical capability matches what was agreed.
Human review required — take this to your counsel
Article 9 — special category data needs its own condition
Processing special category data is prohibited unless an Article 9(2) condition applies, and that is a separate question from the Article 6 basis. In a document corpus the special category data is usually incidental — a sick note in an HR folder, a dietary requirement in an email — which makes it harder to spot and no less regulated.
- Required checks
- Identify the Article 9(2) condition, and where it depends on Member State law, identify that law.
- Sample the corpus for incidental special category data rather than assuming there is none.
- Decide whether some repositories should simply be excluded from the index.
- Vendor questions
- Does your contract permit processing special category data, and are there any carve-outs?
- Technical controls
- Run a detection pass over the corpus before indexing and quarantine what it finds.
Human review required — take this to your counsel
Data governance and measured outcomes, not asserted fairness
The AI Act’s data governance requirements for high-risk systems cover the relevance, representativeness and error profile of training, validation and testing data, and the examination of possible biases. The GDPR accuracy principle points the same way. Both are answered with measurement and a record, not with a statement that the vendor tested for bias.
- Required checks
- Define what a fairness failure would look like for this use case, before measuring.
- Establish a baseline against the process the system replaces, so a comparison is possible.
- Set a review cadence and a threshold that triggers action.
- Vendor questions
- What bias evaluation have you performed, on what data, and will you share the results?
- Technical controls
- Log outcomes with enough structure to analyse them by group, subject to the data protection constraints on doing so.
EU residency is a configuration and a contract, not a default
Regional processing usually has to be selected explicitly and written into the contract. Storage in an EU region says nothing about where inference runs, where logs land, or where support staff sit, and failover to another region can quietly defeat the commitment.
- Required checks
- Get storage, inference, logging and support access covered by the same commitment.
- Establish the failover region and whether the commitment survives failover.
- Vendor questions
- Is EU-only processing available for this model, and is it a contractual commitment?
- Where do logs and telemetry go, and can they be kept in the EU?
- Technical controls
- Pin the regional endpoint and monitor for drift.
Whether your content trains the model, and what the EDPB says about that
EDPB Opinion 28/2024 addresses when an AI model trained on personal data can be considered anonymous — its position is that this cannot be assumed and must be assessed case by case — and when legitimate interest can support developing or deploying such a model. For a buyer the practical question is narrower: does the contract say your content is not used for training, and for how long is it retained.
- Required checks
- Find the training commitment in the contract, not in the marketing page.
- Establish whether abuse monitoring creates a separate retention path with different rules.
- Vendor questions
- Is customer content used to train or improve models by default, and where is that stated contractually?
- If we opt out of training, what is retained, for how long, and who can read it?
A lawful basis has to exist for the AI processing specifically
Article 6(1) reads: “Processing shall be lawful only if and to the extent that at least one of the following applies”, and it applies to each purpose separately. The basis that covered holding employee records therefore does not automatically cover analysing them with a new system. In an employment relationship consent is rarely a sound basis, because of the imbalance between the parties, which usually pushes the analysis to necessity or to legitimate interests and its balancing test.
- Required checks
- Write down the purpose of the AI processing in one sentence, then identify the basis for it.
- Where the basis is legitimate interests, complete and keep the balancing assessment.
- Where data is being re-used, run the Article 6(4) compatibility assessment rather than assuming.
Storage limitation reaches the embeddings
Personal data must be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed. Deleting a source document does not delete its embedding, its cached completion or the prompt that quoted it, and an erasure request under Article 17 reaches all of them.
- Required checks
- Extend the retention schedule to the index, logs, caches and any fine-tuning datasets.
- Test an erasure request end to end before launch, and record the result.
- Vendor questions
- What is your deletion SLA, and does it cover backups?
- Technical controls
- Cascade deletion from source document to embedding to cache.
Standard contractual clauses — the right module, actually completed
The Commission’s clauses provide appropriate safeguards under Article 46(1) and (2)(c) and combine general clauses with a modular approach for different transfer scenarios. The common failure is not the absence of clauses but the wrong module, empty annexes, or a docking clause that nobody completed for the party that later joined.
- Required checks
- Confirm which module applies to the actual relationship, and that it is the one used.
- Check the annexes are filled in with real descriptions rather than "as per the agreement".
- Confirm the transfer impact assessment sits alongside the clauses.
- Vendor questions
- Which module of the 2021 clauses do you sign, and can we see the completed annexes?
Human review required — take this to your counsel
Article 32 — appropriate measures, including for the new stores
Security measures must be appropriate to the risk, taking account of the state of the art and the nature of the processing. For a retrieval system the specific risks are cross-tenant or cross-user retrieval, prompt logs holding content the source system protected, and an index that outlives the permissions it was built from.
- Required checks
- Confirm retrieval enforces the source system’s permissions at query time.
- Confirm the breach process covers the index and the prompt logs, not just the application database.
- Vendor questions
- How is tenant and user isolation enforced in retrieval, and has it been tested by a third party?
- Technical controls
- Encrypt the index and the logs at rest with separate key management from the application.
- Re-synchronise permissions on a schedule so revoked access is revoked in the index too.
The model provider is usually a subprocessor
A processor may not engage another processor without authorisation, and must impose the same obligations down the chain. In an AI product the chain is often longer than the buyer realises: the application vendor, the cloud host, the model provider, and sometimes a separate moderation or evaluation service. Each one is a place your content goes.
- Required checks
- Get the current subprocessor list and read it as an architecture diagram.
- Confirm the notice period before a subprocessor changes, and what you can do about it.
- Vendor questions
- Which model provider do you use, in which region, and is that a contractual commitment or a current fact?
- How are we notified of subprocessor changes, and can we object?
Articles 13 and 14, plus AI Act transparency duties
People have to be told about the processing, and where there is automated decision-making within the meaning of Article 22 they must be given, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject. The AI Act adds its own transparency duties, which have applied since 2 August 2026.
- Required checks
- Update the privacy notice for the specific AI processing, not with a generic AI paragraph.
- Prepare the explanation of the logic in language a person affected would actually follow.
- Check whether interactions with the system need to be disclosed as AI-generated.
- Vendor questions
- What documentation do you provide about how the model produces its output, at a level we can pass on?
- Technical controls
- Label AI-generated content in the interface, not only in the terms of use.
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 material is covered by legal professional privilege.
- Vendor position on "data_residency_region" is not verified.
- Vendor position on "dpa_published" is not verified.
- Vendor position on "subprocessor_change_notice" is not verified.
- Vendor position on "subprocessor_list_published" is not verified.
- Vendor position on "tenant_isolation" is not verified.
- Vendor position on "transfer_mechanism" is not verified.
06Cost range
| Line | One-off plus monthly |
|---|---|
| Software | HK$0 |
| Model | HK$0 |
| Infrastructure | HK$4,500 – HK$11,000 |
| Implementation | HK$84,000 – HK$450,000 |
| Total | HK$89,000 – HK$460,000 |
| From year two | HK$130,000 – HK$490,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: Cloud GPU instance — 1 × NVIDIA L4 24 GB at 0.8–2 USD per hour × 730 hours per month (indicative on-demand rental, USD per hour, Aug 2026 — verify against the provider price list for your region). Stopping the instance outside working hours cuts this roughly in three; committed-use discounts cut it further.
- Excludes storage, egress, backup and the network in front of the instance.
- Implementation: 14–30 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 items (implementation) plus recurring monthly items (rented infrastructure). The total adds them together, so read it as first-year outlay rather than a monthly bill.
- Sized for 12 users. Every figure is an assessment from the inputs listed above, not a quotation.
- From year two this costs roughly HKD 130,000–HKD 490,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 — recurring monthly lines: HKD 4,500–HKD 11,000 per month × 12 = HKD 54,000–HKD 130,000 a year. Software, model usage and rented infrastructure only; the monthly figures are the ones listed above.
- 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
2 / 5
A few days, mostly configuration
- AssessmentStarting point 2/5: your own tenancy to build in, but no hardware to buy or rack.
- 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 Single sign-on adds an identity provider, group-to-role mapping and a joiner/leaver process to the deployment.
- Assessment-0.5 An in-house IT team can run the server, the backups and the identity provider already.
- AssessmentAssessed difficulty 2/5 (2 +0.5 +0.5 -0.5 = 2.5, rounded and capped to 1–5).
08Implementation path
This reference implements the Private-cloud RAG in a single region recipe, which carries the components, the ordered steps, the commands and the evidence behind each one.
- Implementation
- 14–30 FDE-days
- Use case
- Recruitment screening
AssessmentAbove the recipe’s 6–15 day band: this scenario adds a retention job over derived data, an audit log the works council can read, and the consultation itself, which is calendar time the recipe does not carry.
This reference would not suit
- Any team that actually wants ranking or filtering. That is a different system with a different obligation set, and pretending otherwise by calling it "assistance" does not change what it is.
- A team of two handling twenty applications a month. The reading aid is real but the deployment is not worth its own retention job at that volume.
- An organisation with no works council and no German operations, which should re-read this with the German rules removed — several of the constraints above exist because of them.
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.
8 of 8 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.