Internal assistant under control
How can you build a useful prototype without exposing internal documents or bypassing access permissions?
3500 € per session, excl. VAT
In short
Over two days, or 14 hours excluding breaks, design a prototype internal document assistant and its pilot dossier. You define access permissions, prepare a controlled corpus, configure source-referenced answers and test for data leakage risks. The result includes a reproducible evaluation and explicit conditions for limited deployment.
Why this training?
A document assistant can disclose information through its answers, citations or logs. Protection must cover the entire chain, from the user’s identity to the documents retrieved. A convincing demonstration proves neither reliability nor compliance with access rights. The programme confronts the prototype with business questions, prohibited requests and injections to support a pilot decision. Case study used throughout: The fictitious organisation Lysandre Métrologie wants to query its maintenance procedures. Some appendices are restricted to managers. The prototype must answer technicians without revealing these appendices, even when a document contains a malicious instruction. Transfer to the workplace: Before any real pilot, have the dossier validated by those responsible for security and data, rerun the tests in the target environment and appoint a person authorised to suspend the service.
Objectives of this training
- Map document flows and trust boundaries
- Build a prototype with differentiated access permissions
- Configure citations, abstention and trace minimisation
- Run reproducible functional and adversarial tests
- Draft the conditions for launching and stopping the pilot
Who is it for and what are the prerequisites?
Roles and tasks concerned
- Architects and developers responsible for an internal document assistant
- Product managers and security focal points involved in its pilot
Prior skills
- Have practical experience of generative AI and understand augmented document retrieval.
- Be able to work with an API or a prototyping environment.
- Know the principles of authentication and authorisation.
What you will work on
Define the scope of the limited service
Objective: Define the boundaries of acceptable use. Permitted questions, exclusions, responsibilities and acceptance thresholds.
Model threats
Objective: Identify points of exposure. Flows, hosting, storage, secrets and trust boundaries.
Prepare the corpus
Objective: Make sources traceable. Classification, versions, chunking and access metadata.
Implement authorisations
Objective: Restrict document retrieval. Identity, least privilege, filtering before generation; limitations of the prompt.
Assemble the prototype
Objective: Produce verifiable answers. Augmented retrieval, citations, abstention and no autonomous actions.
Build the evaluation
Objective: Measure document quality. Expected references, relevance, refusals and denominators.
Test the safeguards
Objective: Detect bypasses. Indirect injection, extraction and cross-profile disclosure.
Govern logging
Objective: Observe without excessive exposure. Masking, log access, retention and alerts.
Correct and retest
Objective: Verify priority corrections. Criticality, regression and version control.
Decide on the pilot
Objective: Formalise a conditional launch. Limited user group, support, oversight and shutdown.
What you take away
- Architecture dossier and authorisation matrix
- Isolated prototype and version-controlled configuration
- Test report with evidence and anomalies
- Pilot plan with oversight and a shutdown procedure
Method and assessment
- Short input sessions followed by immediate practical work on the continuing case study.
- Individual work followed by work in pairs, with peer review of the outputs.
- Facilitated group discussion: what works, what needs correcting and what remains a human decision.
- Preparation: Have an isolated environment and tools authorised by the organisation available; check their capabilities for differentiated access. Prepare only fictitious or anonymised documents, two user profiles and anticipated questions.
Observable criteria: Prohibited documents remain inaccessible in all cross-profile scenarios tested. ; The assessed answers cite a relevant passage or indicate that the available documentation is insufficient. ; The rates of evidence-supported answers and correct refusals are calculated on an identified set. ; The inspected logs comply with the defined data minimisation rules. ; Every blocking anomaly prevents the pilot from starting until its correction has been verified..
Frequently asked questions
Will the service be made ready for production at scale?
No, the training produces an isolated prototype and a pilot dossier.
Can real documents be used?
Only anonymised and authorised documents; the exercises prioritise a fictitious corpus.
Is a prompt enough to protect access?
No, access permissions must be enforced outside the model, before retrieval.
What should you do if the environment lacks controls?
Document the limitation, simulate the control and block any affected real-world pilot.
Last updated: