IskayPet Knowledge Assistant Moves Corporate Search to Managed Amazon Bedrock

IskayPet built a corporate knowledge assistant spanning four languages and three countries, according to a case study published October 22, 2026. The IskayPet knowledge assistant uses Amazon Bedrock Managed Knowledge Bases to answer employee questions from existing SharePoint documents. Its significance lies in the division of responsibility: AWS operates the retrieval infrastructure, while the business remains responsible for trustworthy knowledge.

Retrieval-augmented generation, or RAG, supplies retrieved documents to an AI model before it answers. The approach gives corporate assistants a reference library beyond their training data. Choosing a managed service changes who maintains that library’s technical machinery, while leaving questions about authority, access, and accuracy with the organization.

The alternative is a customer-managed retrieval system, with more infrastructure choices and maintenance obligations. Microsoft’s SharePoint agents offer another reference point for companies already storing documents there. IskayPet’s deployment makes the managed-versus-custom decision concrete, without establishing that one platform delivers better answers across every organization.

What the IskayPet Knowledge Assistant Changed

According to the jointly authored AWS and IskayPet corporate knowledge case study, the assistant covers retail, veterinary operations, onboarding, and procurement. It supports Spanish, Portuguese, French, and English across Spain, Portugal, and France.

The authors report that finding an operational answer fell from three to five minutes to about seven seconds during roughly two production months. They project approximately 100,000 monthly queries. That figure describes expected demand, rather than demonstrated usage.

The practical change is a shorter route from an employee’s question to the company’s written guidance. That matters because a document repository and an answer interface ask different things of employees.

A repository requires someone to recognize the right file, navigate its structure, and identify the relevant passage. An assistant attempts to perform those steps before presenting an answer. The employee then has to judge whether the response addresses the actual situation.

That shift changes the location of effort. Less time spent opening documents can leave more time for checking the applicable rule. However, a quicker response also makes it easier to accept an answer before examining its source.

Consider an illustrative return-policy question. An employee might ask whether an exception applies to a particular purchase. A useful answer would identify the applicable policy and preserve its conditions. A fluent summary that omits an exception would create a different operational outcome.

The same distinction applies to onboarding. Finding a general checklist helps only if it matches the employee’s role and location. A system can retrieve a relevant document while still selecting an instruction that belongs to another context.

Those examples explain why the reported speed improvement deserves attention without becoming a complete business case. Retrieval time is one component of task completion. Verification, escalation, and correction also consume employee time.

A meaningful comparison would follow the entire question through resolution. Did the employee finish the task correctly? Did a manager still need to intervene? Did the answer prevent another search, or simply move it elsewhere?

The publication documents a company deployment, rather than a new general-purpose model release. Its news value comes from applying managed retrieval to a recurring operational problem. The consequences depend on how reliably that application handles ordinary work.

For enterprise buyers, the useful takeaway is therefore specific. An answer interface can improve access to established guidance. Measuring its value requires examining what employees do after receiving the response.

Managed Infrastructure Changes the Enterprise Buying Decision

Managed retrieval shifts the buying decision toward application quality, operational fit, and accountability. Engineering effort remains relevant, but maintaining search infrastructure becomes a different part of the calculation.

AWS’s documentation says managed knowledge bases handle ingestion, storage, indexing, and retrieval infrastructure. Ingestion brings source material into the system; indexing organizes it for search. The service also supplies managed embedding and reranking models.

Embeddings represent content numerically for similarity searches, while reranking reorders retrieved material by relevance. AWS distinguishes this arrangement from customer-managed knowledge bases, where customers provision and maintain their underlying data stores.

That distinction gives engineering leaders a clearer question. Which infrastructure decisions create an advantage for this application? If the requirement is access to routine internal guidance, a custom storage architecture needs a concrete justification.

A company might need unusual retrieval behavior, specialized controls, or deeper infrastructure visibility. Those requirements can justify additional engineering ownership. They should be evaluated against actual application needs rather than treated as automatic prerequisites.

The managed route changes the pressure on internal development proposals. A team requesting a custom system must explain what additional control delivers. “We need a chatbot” provides little guidance about why the company should operate its own retrieval components.

The same pressure reaches vendors. A supplier selling infrastructure flexibility needs to show where that flexibility improves the customer’s outcome. Another supplier selling simplicity needs to explain the boundaries of its managed service.

Neither proposal can be assessed through a feature count alone. A broader configuration menu has value only when the organization can use it effectively. Fewer configuration choices have value when the defaults meet the workload’s requirements.

For buyers, Amazon Bedrock retrieval therefore becomes part of a wider ownership decision. Who diagnoses missing answers? Who reviews changes? Who maintains the test questions? Who can explain why an employee saw a particular result?

Those responsibilities need explicit owners even when the underlying service operates correctly. A connector can successfully ingest a document that the business should have retired. A search system can correctly surface content whose permissions were assigned too broadly.

This is also where procurement should separate technical support from editorial responsibility. A service provider can investigate a failed request. It cannot independently decide which internal policy represents the company’s current position.

Cost comparisons need similar care. Infrastructure spending captures only part of the application’s economics. Content review, employee support, evaluation, and incident investigation also require staff time.

A managed service deserves credit for work it removes. A fair assessment also identifies the work that remains. That creates a more useful comparison than describing either architecture as effortless.

The strategic implication is a higher standard for enterprise AI proposals. Teams should connect architecture choices to measurable operational requirements. The ability to assemble a retrieval system is only the starting point.

Separate Assistants Put Business Boundaries Into Search

The case-study authors say IskayPet chose a separate knowledge base for each assistant, scoped to selected SharePoint content. Retrieval applies employees’ existing document permissions.

This design makes the scope of an answer an explicit product decision. It raises a question that a broad corporate search box can obscure: which body of knowledge should answer this request?

A shared index promises a convenient destination for every question. That convenience requires the application to distinguish among overlapping departments, locations, and document purposes. An answer can sound relevant while drawing from the wrong organizational context.

Separating assistants changes that problem. Each assistant starts with a narrower set of possible sources. The organization then has to make those boundaries understandable to employees and maintain them as responsibilities change.

That is a tradeoff between broad discovery and deliberate scope. A narrower assistant can make its purpose easier to explain. It can also leave a cross-department question outside any assistant’s complete view.

Imagine an illustrative question combining a purchasing exception with an onboarding requirement. Procurement guidance might answer part of it, while people operations guidance answers another part. The interface needs a sensible response when the question crosses those boundaries.

Possible responses include asking for clarification, identifying the missing context, or directing the employee to another owner. The appropriate choice depends on the workflow. Quietly presenting a partial answer as complete would hide the limitation.

This is why assistant boundaries belong in product design discussions. They determine what users can reasonably expect from the system. They also influence how failures should be explained.

Permissions introduce another distinction. Access answers whether an employee is entitled to read a document. Applicability answers whether that document governs the situation. Those are related questions with different consequences.

An employee might legitimately access guidance from several locations. That does not make every policy equally applicable to a local task. The assistant needs enough context to preserve that distinction.

Similarly, language should not become an accidental substitute for geography. A person asking in English might need a local policy written in another language. A system that follows language similarity alone would risk choosing the wrong authority.

These are analytical implications of the architecture, rather than evidence of observed failures at IskayPet. They explain what another company should examine before copying the design.

Microsoft provides a useful comparison. Its SharePoint agents use selected sources and respect users’ content permissions. Microsoft also describes access through SharePoint, Teams, and Microsoft Copilot.

That establishes an alternative approach for organizations evaluating the same document estate. It does not provide a performance comparison with IskayPet’s deployment. Choosing between them requires testing the organization’s own questions, identities, and workflows.

The broader competitive point concerns ownership. Companies can compare an assistant embedded in their collaboration environment with an application assembled around managed cloud services. The relevant advantage depends on integration requirements and operational control.

For readers comparing team knowledge bases, the distinction is foundational. A shared collection of documents becomes useful when its boundaries, authority, and audience are clear.

Multilingual Corporate Search Raises the Bar for Evidence

Multilingual corporate search needs evidence that an answer preserves the applicable rule across languages. A natural-sounding response does not establish that it kept every condition intact.

Translation can make information accessible while changing how a qualification sounds. A recommendation, requirement, and exception carry different operational meanings. An evaluation needs to check those meanings rather than reward fluency alone.

An illustrative policy might distinguish between what an employee can approve and what requires a manager. A shortened answer could preserve the main instruction while dropping the approval condition. The result would read well and still guide the wrong action.

That creates a demanding evaluation problem. The system must find the right information, interpret the question, and express the answer appropriately. Testing only the final wording makes it harder to locate the source of a mistake.

AWS’s retrieval evaluation documentation separates retrieve-only evaluations from retrieve-and-generate evaluations. The former examines retrieved information; the latter also examines generated responses. This provides a basis for assessing different stages separately.

That separation matters when comparing Amazon Bedrock retrieval configurations. If the applicable document never enters the retrieved material, rewriting the answer prompt addresses the wrong failure. If retrieval succeeds, the generation stage becomes a more useful focus.

For an enterprise buyer, the practical implication is better diagnosis. “The assistant was wrong” describes an outcome. It does not distinguish a missing document from a misunderstood condition or an incorrect assumption about location.

Evaluation questions should therefore carry operational context. A bare question such as “What is the process?” leaves too much unspecified. A realistic question identifies enough of the situation to establish what a correct answer requires.

Some tests should intentionally withhold that context. A reliable assistant should recognize when clarification is necessary. Confidently choosing a location or department can be worse than asking the employee a brief follow-up.

Equivalent questions across languages offer another useful check. The wording need not match literally. The applicable policy, required action, and relevant exceptions should remain consistent.

Local reviewers matter because they can identify differences that a generic language assessment misses. A grammatically correct sentence can use an unfamiliar term or weaken an obligation. Those defects affect whether employees can act on the answer.

The results should also remain visible by language and business area. An overall score can hide a weaker experience for a smaller employee group. Aggregate performance does not explain where the application needs attention.

Microsoft’s documentation similarly cautions that generated content can be inaccurate or outdated and should be validated. That is a useful competitive reference because it keeps the comparison grounded in shared evaluation needs.

The strongest evidence would combine language checks with actual task outcomes. Could the employee identify the applicable procedure? Did the answer retain the exception? Did the source support the action?

Those questions make multilingual support more meaningful. They assess whether the system carries corporate knowledge across languages without losing the distinctions that make the knowledge useful.

Reported Speed Gains Leave Quality and Governance Questions Open

The published account does not provide a benchmark dataset or detailed language-specific accuracy scores. Its reported timing improvement therefore supports a narrower conclusion than a full assessment of operational effectiveness.

Faster answers and dependable answers require separate evidence. A retrieval application can improve the former while leaving important questions about the latter unanswered.

This qualification reflects the available evidence. It is not an allegation that the deployment produces unreliable responses. A customer case study can offer useful architectural details without supplying everything needed for an independent evaluation.

The missing benchmark methodology matters when interpreting a before-and-after comparison. Readers need to know whether the same kinds of questions appeared in both measurements. They also need to know whether the timing ended at response delivery or successful resolution.

Question difficulty can change the result. A straightforward lookup differs from a request that combines exceptions across documents. Measuring both together without describing the mix makes the average harder to interpret.

Usage projections deserve similar discipline. Expected demand can inform capacity planning. Demonstrated adoption requires evidence that employees continue using the application for relevant work.

A high query count alone would still leave ambiguity. It might reflect useful repeat engagement, or repeated attempts to obtain an acceptable answer. Resolution rates and correction patterns would help distinguish those possibilities.

Source quality introduces a separate governance issue. An assistant can accurately summarize a superseded policy. Its answer would be faithful to the retrieved text while remaining unsuitable for the employee’s current task.

The organization therefore needs a way to identify current authority. Document ownership, review dates, and replacement procedures become part of the answer system’s practical reliability. Search quality cannot resolve an unresolved disagreement between policy owners.

Permissions require their own review. Preserving an existing access rule preserves the decisions already encoded in that rule. It does not determine whether those earlier decisions remain appropriate.

That distinction becomes more consequential when information is easier to discover. Material that employees rarely encountered through browsing can become readily available through a direct question. The business needs to understand that change in accessibility.

Content controls address another category of risk. AWS describes Bedrock Guardrails as configurable safeguards for inputs and responses, including sensitive-information filtering and contextual grounding checks. Grounding checks assess whether responses remain supported by supplied material.

Those capabilities should be evaluated for their intended purpose. Filtering an unsuitable response does not establish that the underlying policy is current. A permission check does not establish that a summary is complete.

A credible governance model assigns each responsibility explicitly. Policy owners maintain authoritative guidance. Application owners investigate answer behavior. Security teams assess access. Employees need a clear route to report an answer that appears wrong.

For buyers, these questions sharpen the value of the IskayPet knowledge assistant story. The reported improvement is worth examining. Establishing repeatable value requires evidence beyond response speed.

The Next Evidence Should Track Quality, Access, and Sustained Use

The most useful follow-up would show whether the deployment keeps producing correct, appropriate answers as documents and usage change. Over the coming months, three signals deserve attention.

First, look for evaluation results broken down by language and business function. Those results should explain the question set, the expected answer, and how reviewers judged correctness. That would make the reported benefit easier to assess.

Stronger results across those categories would support confidence in wider use. A persistent gap in one category would suggest a narrower conclusion. Either outcome would be more informative than a single overall satisfaction figure.

The evaluation should also include questions that the assistant cannot answer from its sources. Recognizing insufficient evidence is part of useful performance. An application that asks for clarification can protect the workflow from an unsupported assumption.

Changes to models or retrieval settings offer another opportunity for evidence. A follow-up could compare the same representative questions before and after a change. That would help separate improvement from ordinary variation in employee requests.

Second, look for evidence about source updates and access changes. A production assistant needs to respond appropriately when a policy changes or an employee’s entitlement ends. Static demonstrations cannot establish that behavior over time.

Useful evidence would explain when revised guidance becomes available to answers and how obsolete guidance stops influencing them. It would also show how access changes affect subsequent requests.

Consistent behavior would strengthen the managed-service case for this workload. Delayed updates or unclear responsibility would expose additional operational work. The relevant question is whether the company can detect and resolve those conditions predictably.

This signal also concerns administration. Adding another assistant should come with a clear owner, source scope, and review process. Expansion creates value when those responsibilities remain manageable.

Third, look for sustained adoption alongside successful resolution. Actual demand would put the published projection into context. Repeat usage, source verification, escalation, and correction patterns would explain more about employee value than traffic alone.

Steady usage with fewer avoidable escalations would support the operational argument. Frequent reformulations or unresolved questions would point toward usability or knowledge gaps. Those patterns deserve investigation even when response delivery remains fast.

None of these signals requires a contest over which company has the most capable general model. They concern the performance of a specific application against a specific document estate. That is the level at which an enterprise purchase becomes defensible.

For teams evaluating a similar investment, begin with a bounded business question and an authoritative set of documents. Compare how candidate systems handle ordinary requests, missing context, revised policies, and restricted access. Ask local reviewers to judge whether the answers preserve the instructions employees actually need. Keep response speed visible alongside successful resolution, correction effort, and ongoing administration. The IskayPet knowledge assistant provides a concrete deployment to examine, while your own evidence should determine the architecture choice. Before approving a broader rollout, ask the team to show which operational decisions improved and which uncertainties remain. What evidence would establish that employees can rely on the answer?