Start with one answerable operational question
Kooya analysis: a useful first scope is narrower than “chat with everything.” Consider an illustrative distributor whose branch staff need the current procedure for receiving damaged stock. The assistant should find the applicable procedure, identify the version and explain the next step. It should not improvise a compensation promise or expose another customer’s correspondence. This is a design example, not a Kooya client result.
Write an answer contract before collecting files: which questions are in scope, which source is authoritative, who can ask and who handles an unresolved case. An owner should be able to read that contract without needing to understand embeddings. If the team cannot identify the approved procedure today, adding an AI interface will not settle the disagreement.
- Define one collection, one user group and one operational owner.
- List excluded documents and excluded actions explicitly.
- Keep transactional decisions outside the initial document-answering scope.
Understand what retrieval actually adds
Microsoft describes retrieval-augmented generation, or RAG, as retrieving relevant content and placing it alongside a question for a model to answer. An index can support search and store citation metadata. This is a way to supply context; it does not establish that every answer is correct.[1]
Kooya analysis: separate three purchase decisions. You need a place where approved knowledge lives, a retrieval layer that selects useful evidence and an answer interface that presents it faithfully. A single product may supply all three, but your evaluation should still expose them individually. Ask a supplier to show the selected passages when an answer fails, rather than simply changing the model.
For a first comparison, keep a conventional search view available. If users already know a document title, a direct link may be more useful than a generated explanation. Reserve synthesis for questions where combining passages genuinely helps complete the task.
Carry permissions through the entire path
Microsoft’s engineering account of a SharePoint retrieval pipeline explicitly carries document permissions into the search index and filters results for the authenticated user. It also identifies a limitation: stored permissions can become stale between synchronization runs. The example is an architecture report, not a guarantee about every connector or deployment.[2]
Kooya analysis: test the boundary using two test accounts. One can access the sample procedure and one cannot. Ask the same question as both, then revoke the first account’s access and repeat. Inspect search results, citations, generated text and conversation history. Agree how quickly revocation must take effect and what happens while the permission service is unavailable.
A prompt saying “do not reveal confidential files” is not an access-control design. Keep unauthorized material out of the model context. Where the product caches answers, verify that a response generated for one identity cannot be served to another merely because the question matches.
Make freshness and citations part of the answer
Kooya analysis: store an authoritative source link, document owner, revision or effective date and last successful synchronization time. These fields answer different questions. A file retrieved this morning may still contain a procedure withdrawn last month. The newest upload is not necessarily the approved version.
Create a replacement test: publish a revised sample procedure, remove its predecessor and ask a question whose answer changed. The result should follow the approved replacement and link to it. Then delete the source entirely. Verify what remains in the index, cached answers and retained transcripts; these surfaces may need different retention rules.
Review citations at the claim level. Does the cited passage support the quantity, exception or instruction in the sentence? If two approved sources conflict, show the conflict and route it to the owner. Do not allow a confident tone to hide an unresolved source decision.
Apply Philippine personal-data requirements to the actual scope
NPC Advisory No. 2024-04, dated 19 December 2024, explains that Philippine data-protection obligations apply when AI development or deployment processes personal data, including training and testing. It addresses lawful basis, transparency, accountability, security and governance measures including privacy impact assessments. It also calls for excluding personal data unlikely to improve the system by default.[3]
Kooya implementation recommendation: before ingestion, have the organization’s privacy lead review the selected files, intended purpose, user groups, service providers, retention and deletion path. A procedure manual may be a simpler starting collection than individual personnel or customer records. Do not treat a pilot label, a vendor feature or this engineering checklist as a finding of legal compliance.
Treat instructions inside documents as untrusted
OWASP identifies indirect prompt injection as instructions entering through external content such as files or websites. Its guidance states that RAG does not eliminate this risk and recommends controls including limited privileges, separation of untrusted content and adversarial testing.[4]
Kooya analysis: the first knowledge-base pilot can remain read-only. It should answer from evidence, not send messages, change accounts or approve transactions. Use harmless test documents containing irrelevant instructions and check that they remain quoted evidence rather than commands. Record failures for the system owner; a passed sample is not proof that all injection attempts will fail.
Test the retrieval before judging the writing
Kooya’s proposed acceptance set contains answerable questions, genuinely missing answers, contradictory sources, revoked access, changed procedures and equivalent questions in the team’s working languages. For a Taglish-speaking operations team, write natural questions with local abbreviations rather than translating every English sentence word for word.
Review each failure in two stages. First ask whether the correct, authorized passage was available and selected. Then ask whether the answer accurately represented that passage. This prevents a writing adjustment from masking a broken index, and prevents a retrieval adjustment from masking unsupported conclusions.
Choose acceptance thresholds with the workflow owner before the trial. Track task completion, unsupported claims, authorization failures, citation support, unresolved questions and review effort. An access failure should trigger investigation even when the average answer score looks good. Compare complete task time against existing search, including corrections and escalation.
Use the AI pilot evaluation checklist to turn those acceptance criteria into a rollout decision.
- Keep the expected source and expected access outcome for every test question.
- Record why the system declined; an appropriate refusal can be a correct result.
- Retest after changing connectors, document processing, models or permissions.
Buy an operating arrangement, not just a chat window
Kooya analysis: ask who fixes a failed synchronization, who approves new collections and who reviews unanswered questions. Request evidence from a bounded demonstration using authorized sample material. A supplier should explain which controls come from the product, which require configuration and which your own organization must operate.
Ask for a cost breakdown that includes ingestion, recurring synchronization, retrieval, model usage and human maintenance. Also ask how to export document metadata, evaluation examples and logs when changing providers. Avoid treating an attractive prototype as evidence of a support model or a predictable monthly bill.
The next step is a scoped brief: the collection, identities, answer contract, freshness requirement and acceptance set. Bring that to a builder or vendor. It creates a clearer conversation than asking for an AI trained on all company data.