Hey there 👋, I’m Bryan

Welcome to my newsletter. I share practical advice and tackle tough questions on putting AI to work. Thanks for being here! Send me your questions and in return I’ll humbly offer actionable real-talk advice 🤜🤛

In my recent article on prioritizing AI ideas, one of the examples was an increasingly common request from business leaders: building an enterprise “brain.”

It seems everyone wants to build an AI chatbot that can deliver on-demand information about how their organization works. Human Resources wants help explaining policies and onboarding to employees. Finance wants quick answers about spending limits and approvals. Operations wants guidance on claims, refunds, and exceptions.

The request sounds simple: give us one place to ask a question and get an answer we can use (and trust!). Preferably without opening six applications, finding three conflicting documents, and eventually messaging the person who somehow knows everything.

I understand the appeal. In my Copilot article, I was able to find a company policy just by asking chat, and it was one of the benefits I appreciated most. But it raises a couple of questions: how does it find the right answer, and who makes sure the answer is right?

First I’ll walk you through the underlying problem, but fair warning: it gets messy, even before a AI enters the picture.

Who owns the enterprise brain?

Should each department have its own chatbot, or should all employees have one enterprise chatbot? Who maintains the information?

My preference is one obvious entry point, supported by departmental expertise and shared rules for company knowledge. People should be able to ask, “How do I get this approved?” without first studying the chatbot org chart.

Behind that centralized interface each department owns the knowledge within their domain. Marketing owns brand guidelines, Human Resources owns HR policy, and so forth. Specialized AI chatbots may serve different teams and workflows, but they shouldn't create new silos of company knowledge. When chatbots answer the same question, they should rely on the same approved information, with appropriate permissions.

Central system nightmares

A central system sounds great, in theory. But it needs an owner and a maintenance process.

Imagine a company that has grown through dozens of acquisitions. Each acquired company brings its own policies, procedures, and documented customer knowledge, which someone could thoughtfully migrate into one shared documentation system.

You have a central system. You might also have a nightmare.

Moving everything into one location can sound like a great idea. But what happens if no one is responsible for verifying the information’s accuracy, deciding who can access it, or keeping it current? Critical customer information becomes outdated, inaccessible, or difficult to find.

Now imagine putting an AI chatbot in front of all that data. Easier access wouldn’t solve the underlying problems. An AI chatbot needs dependable information to draw from, which means knowing which documents and data are current, accurate, and approved. Skip ahead for six steps to building a dependable company knowledge database for AI.

I’m talking about a maintained collection of company policies, procedures, customer knowledge, and approved guidance that AI can consult.

“Maintained” is doing a lot of work in that sentence.

Reimagine the work

The idea of connecting a chatbot to company knowledge for on-demand reference is game-changing. Organizations have the opportunity to rethink how their company information is created, approved, shared, and maintained.

If you have read The Enterprise Brain: Rewiring Your Business for the AI-Native Era, co-authored by Target’s Chief AI Officer, Chandhu Nair, you might be familiar with this comparison I’m about to make.

When factories were powered by steam engines, production floors had to be designed around a single power source. From building design to machine placement, factory layouts were constrained.

Electricity opened the door to reimagining how the floor was organized. Machines could be placed in the production sequence, rather than based on power needs. Everything could be more efficient and focused around workflow and efficiency.

So what does this have to do with AI transformation? Factories didn’t redesign themselves overnight. At first, layouts remained the same and the steam engine was simply replaced with an electric motor. Only when factories transformed their design did they see the full benefits of the new technology.

The same principle applies to an enterprise brain. Connecting AI to your existing documents might improve access, but the bigger opportunity is to rethink how company knowledge is created, approved, maintained, and shared.

Six steps to building a dependable company knowledge database for AI

1. Pick one process and the questions it needs to answer.

“Connect all our documents” is a tempting starting point. It also creates an enormous cleanup project before you’ve defined what success looks like.

Choose a single process that is frequently queried, such as employee onboarding, expense approval, refunds, or customer support. Talk to the people doing the work and collect the questions people actually ask.

For expense approval, that might include:

What can I spend without manager approval?
Does the limit change for international travel?
Which policy applies to an expense from last month?
Who can approve an exception?

Next, define what the chatbot should be able to do. Finding the policy and explaining the approval process is one possible (and recommended) scope. Submitting the expense or approving it is a different project altogether. Make that distinction early so everyone knows what you’re building and what information is required.

2. Find approved sources and put someone’s name on them.

Gather the documents used for that process. Look for duplicates, outdated versions, and conflicting instructions. Ask the process owner to resolve disagreements before those documents become approved sources for the chatbot.

This is where you may discover that three departments have been following three different versions of the same procedure. Congratulations, your AI project has uncovered a process problem! (spoiler: this is guaranteed to happen)

Assign an accountable owner to each approved source and identify who can approve changes. Include a review date and a simple way for users to report errors. Those reports should reach someone who can fix the source.

Tip: An owner needs time and the authority to do this work. Putting a name at the bottom of a document won’t help much if maintaining it never makes it onto that person’s priorities, or if people make their own changes.

3. Make it clear when the information applies.

A policy can be well-written and still be the wrong policy for the question.

An expense limit might apply to one country, one business unit, or purchases made after a particular date. A customer may have contract terms that differ from your standard service offering. Your chatbot needs those distinctions to answer accurately.

For each policy, record its approval status, version, effective date, owner, and scope. Identify which version it replaces and whether it is approved for customer use. For customer documentation, record when someone last checked it and who is responsible for the next check.

Keep the content readable. Use clear headings, consistent terms, and procedures people can follow. Keep conditions and exceptions alongside the instructions they qualify. Suppose your refund window changes next month. The new policy may already be approved, but it shouldn’t govern today’s purchases just because it’s the newest file. And the previous policy may still matter when someone asks about an earlier transaction. “Use the latest document” sounds reasonable until you get a question like that.

4. Define what the chatbot can use, say, and do.

Your implementation team needs clear rules for selecting sources. The chatbot should use approved information that applies to the question, and it should check access controls before restricted content reaches the model.

Ask it to identify the source supporting its answer, including the version when that affects the result. If it needs a purchase date or location, it should ask. If approved sources disagree, it should route the question to the owner.

Then decide what actions it can take. For a refund, there are at least three separate responsibilities:

Explain the refund terms.
Determine whether the purchase qualifies.
Issue the refund.

Each requires the right information and authority. Being able to explain a policy doesn’t automatically allow permission to act on it.

This becomes especially important when a chatbot, utilizing the same underlying knowledge, interacts with your customers. A customer who sees “you qualify for a refund” will reasonably expect the company to follow through. Define when the chatbot must hand the case to a person, and make that handoff useful by including the context already collected.

5. Plan what should happen when something changes.

You’ve approved the source, connected the chatbot, and checked a few answers. Ready to launch?

Almost. What happens when Finance changes the spending limit next week?

Someone needs to approve the revision, record when it takes effect, and ensure the chatbot’s searchable content reflects the change. The previous version should leave current-policy results when its replacement takes effect, while remaining available for historical questions.

Remember saved summaries and memory, too. If the system stores a policy summary, keep a reference to its source and version so you can identify what needs updating or removing. Before a policy-dependent action, require a fresh check of the applicable source.

Otherwise, you can update the official document while the chatbot continues using yesterday’s answer from an earlier conversation. That’s a frustrating way to discover your update process is incomplete.

6. Test the situations that make people hesitate.

Start with questions that have known answers, then test the exceptions. The routine questions tell you whether the setup works at all. The awkward ones tell you whether it’s ready for actual work.

Here’s a useful starting set:

Change a policy in a test environment, then ask about it again in the same conversation.
Add an approved policy with a future effective date.
Ask about a transaction covered by an earlier policy.
Test a regional exception.
Ask the same question as users with different access permissions.
Refer to a previous case where someone received a special exception.

Check the answer, its supporting source, and any action the chatbot attempts. Does it ask for missing facts? Does it recognize when it needs a person?

Fix the failures before expanding. Then keep these scenarios and rerun the relevant ones when sources or system behavior change. You’ve put effort into defining what a correct answer looks like; make that work useful beyond launch day.

One technical tip: make your policies readable by AI

Most organizations I’ve worked with store their policies as PDFs. That works well for human eyes, but isn’t always ideal for an AI that needs to search and interpret those policies.

One alternative is Markdown, a simple, plain-text format that preserves structure through headings, lists, and tables without the formatting complexity of a PDF. This can make information easier for AI to process and retrieve, potentially improving speed and reducing token costs.

Consider maintaining AI-accessible Markdown versions of your policies, ideally generated automatically from the approved originals. But if that means manually maintaining two sets of files, skip it. A well-managed PDF library is better than an outdated Markdown library.

Whatever format you choose, the priority is the same: give AI reliable access to accurate, current information without creating more work for the people responsible for maintaining it.

In Summary

Building an enterprise brain isn't really about connecting a chatbot to your company documents. It's about creating a dependable way to access, maintain, and apply company knowledge.

Start small, establish ownership, and prove that the system can deliver accurate answers even as policies and processes change. Then expand.

Give the chatbot something worth being confident about.

Sincerely,
Bryan 👋

PS - Who keeps your company’s knowledge current today? Let me know in the comments, especially if you’ve already tried connecting it to AI. I’d love to hear what worked and what got messy.

AI at Work

Building an enterprise brain