Give AI the Right Information—Not All Information

Public models can explain a general concept, but company work depends on company context: the current protocol, approved response, quality procedure, product position, submission history, vendor agreement, study decision, controlled template, or operational record. The information layer makes the difference between a generic assistant and a workflow capability.

The problem is not solved by giving the model broad access. Enterprise repositories contain drafts, superseded versions, duplicates, restricted material, records with different retention obligations, and content written for different audiences. A user may have access to a document but still need guidance about whether it is appropriate for a particular intended use. Retrieval has to respect both technical entitlement and workflow meaning.

We start with the work product and reverse-engineer the required evidence. What must the user produce or decide? Which claims, fields, calculations, or comparisons need support? Which sources are authoritative? What source state is valid? What should happen when no suitable evidence exists? This creates a precise information contract instead of an open-ended request to “connect the knowledge base.”

The information contract also defines what the AI output must expose. Depending on the workflow, that may include inline citations, source links, document identifiers, dates, version or lifecycle status, extracted passages, confidence limitations, unanswered questions, and the identity of the review step. The objective is not to make a probabilistic system appear certain. It is to make verification practical.

The right retrieval result is not the most semantically similar text. It is relevant, permissible, current, and reviewable evidence.

A governed architecture begins with a source map. We document repositories, systems of record, content classes, owners, lifecycle states, key metadata, access models, interfaces, volumes, update behavior, and known quality issues for the selected workflow.

Life-sciences information may span Veeva Vault applications, document management, eTMF, QMS, RIM, safety platforms, LIMS, ELN, CTMS, EDC, CRM, content-management systems, shared drives, Egnyte, SharePoint, Teams, data warehouses, specialist databases, email, and external scientific sources. Listing systems is not enough; the same concept can appear in several places with different levels of authority.

We identify precedence rules. A controlled effective procedure may supersede a working copy. An approved core data sheet may govern a product statement while local materials add country context. A final clinical study report has a different role from an analysis notebook. A curated scientific bibliography and a web search should not be presented as equivalent evidence. These distinctions become retrieval filters, workflow rules, or user guidance.

Content lifecycle matters after launch. New versions are approved, documents expire, permissions change, studies close, products change status, and people leave the organization. The design specifies update and deletion behavior, synchronization delay, index reconciliation, and how stale content is detected. A proof of concept that only adds documents is not an operational information service.

Where metadata cannot reliably express authority, we use a proportionate remediation: a curated collection, additional labels, a registry, content transformation, repository rules, or workflow-specific filtering. The first goal is a dependable path for selected use cases, accompanied by a backlog for broader information governance improvements.

An AI request can cross the user interface, orchestration service, model endpoint, connector, retrieval index, source API, logging layer, and monitoring stack. The effective information boundary is only as strong as the weakest hop. We make those trust boundaries explicit.

Identity patterns vary. Some platforms support delegated user access and source-level permission trimming. Others rely on a service identity, synchronized access-control lists, separate indexes, or application-enforced filtering. Each pattern has different risks, operational demands, and testing needs. We document where authorization is decided and how changes propagate.

Service accounts require special attention. A highly privileged service may be convenient for indexing but can create broad exposure if application filters fail. We prefer least privilege, constrained scopes, audience-restricted credentials, secret management, isolated environments, and explicit monitoring. Where a platform cannot support the required access model, we redesign the scope instead of representing the limitation as solved.

Data handling also includes model-provider terms and technical settings: retention, training use, subprocessors, region, encryption, administrator access, abuse monitoring, telemetry, and support access. Contractual promises and product controls are evaluated together. The engagement can organize evidence and technical findings, but the client’s legal, privacy, security, and procurement owners make the relevant approvals.

Negative testing is essential. We test that a user cannot retrieve restricted content, that removed permissions take effect, that source filters cannot be bypassed through phrasing, that citations do not expose titles or snippets from inaccessible documents, and that logs do not collect unnecessary sensitive content. Successful answers alone cannot demonstrate a safe boundary.

Retrieval-augmented generation combines several imperfect stages. Documents are parsed and segmented; queries are interpreted; candidates are retrieved and ranked; context is assembled; a model generates an answer; citations are attached. Fluent output can hide a failure at any stage.

We build an evaluation set from real information needs and known edge conditions. The set includes direct lookups, synthesis across sources, similar terms with different meanings, product and study identifiers, date-sensitive questions, obsolete versions, tables, scanned content, missing answers, restricted documents, and questions where the assistant should ask for clarification.

Evaluation separates retrieval from generation. Did the system retrieve the correct source? Did it include necessary context? Did filters preserve status and permissions? Did the answer remain faithful to the retrieved passages? Are citations attached to the claims they support? Did the system acknowledge conflicts and missing evidence? This decomposition makes improvement targeted and regression testing possible.

Document preparation is workflow-specific. Chunking a procedure, a clinical table, a submission sequence, and a slide deck in the same way usually produces weak context. Structure-aware parsing, headings, tables, metadata, parent-child relationships, controlled vocabulary, and hybrid lexical-semantic retrieval can materially improve results. We add complexity only where evaluation demonstrates a need.

Performance and cost are part of quality. Users abandon slow tools or work around limits. We measure response time, synchronization time, index growth, model and embedding consumption, connector throttling, error rates, and support burden. The target is a dependable service whose economics fit the value of the workflow.

There is no universal life-sciences AI stack. Native enterprise search may be enough for one workflow; another may require a secure connector and structured orchestration; a high-control use case may require a privately hosted model or a tightly curated evidence package.

Native platform capabilities reduce integration and operational burden when the AI service already enforces enterprise identity, respects source permissions, exposes usable citations, and meets the company’s data-handling requirements. We still test these claims against the selected workflow and document limitations. “Native” does not mean automatically sufficient.

Connector and model context protocol patterns can expose tools or resources to an assistant without copying all content into the model environment. They require careful schema design, authentication, authorization, tool descriptions, result limits, logging, and prompt-injection defenses. Tool access should be narrow, observable, and understandable to the user.

Retrieval services provide more control over parsing, indexing, ranking, metadata, evaluation, and orchestration. They also create more components to secure and operate. The design covers ingestion, updates, delete propagation, permission representation, tenant separation, secrets, observability, model routing, fallbacks, and disaster recovery according to business need.

Curated reference packs can be the right first pattern for a bounded workflow. They create a small, reviewed evidence set with known ownership and update cadence. This can produce value and learning while broader repository integration is evaluated. A smaller trustworthy corpus often outperforms broad access to poorly governed material.

Information-layer controls can support regulated workflows, but the assurance approach depends on how the output is used and on the organization’s quality system. We avoid both extremes: treating every AI lookup as a validated GxP system, or assuming citations make a consequential use safe.

The engagement documents intended use, users, sources, boundaries, risks, requirements, configuration, interfaces, evaluation, access testing, known limitations, operational procedures, and change ownership at a level appropriate to the use case. Where formal validation applies, these artifacts can support the client’s lifecycle and traceability approach.

Part 11 applicability is not determined by the presence of AI. It depends on electronic records and signatures within the regulated process. Similarly, GxP relevance depends on the system’s role and use. The organization’s quality and regulatory stakeholders should make those determinations. We provide technical and process evidence and help translate requirements into testable controls.

Models and managed services change. The ongoing plan defines which changes require assessment: model updates, embedding changes, parsing changes, source schema changes, connector releases, permission logic, prompting, ranking, and platform terms. Evaluation sets and negative-access tests create practical regression evidence.

Operational evidence includes incidents, access failures, retrieval misses, unsupported claims, stale sources, synchronization delays, user feedback, and exceptions. Review cadence follows risk and change rate. The information layer is a maintained product, not a one-time index build.

A typical engagement progresses from workflow and source discovery through architecture, prototype, evaluation, security review, controlled release, and operational handoff. The scope can support one department wave or establish a reusable enterprise pattern.

Discovery produces a workflow information contract, source map, access matrix, architecture options, risk and dependency log, evaluation strategy, and recommended delivery scope. This can stand alone when a company needs a decision before implementation.

Implementation produces the configured connector, tool, retrieval service, or native platform pattern; infrastructure and configuration records; test evidence; evaluation results; operational dashboards where appropriate; user and administrator guidance; and a clear list of known limitations. We work with the client’s platform, security, data, quality, and application owners.

Handoff defines service ownership, support routing, source onboarding, access administration, change assessment, evaluation maintenance, incident response, and cost review. If IntuitionLabs continues as a managed acceleration partner, these activities enter a transparent service backlog and review cadence.

The success criterion is not that a chatbot can answer a staged question. It is that authorized users can obtain useful, inspectable evidence from the correct sources; prohibited access fails; updates and deletions propagate; limitations are understood; and someone is accountable for the service after launch.

A governed information layer gives an AI system permission to be useful—and a boundary within which it must remain.