How to Build a Company Brain: Automating New Employee Onboarding with AI

A company brain is a set of approved company pages, each with an owner, that an AI assistant searches and cites using the permissions of whoever asks. To onboard new employees faster with one, build it around one cohort's first-month tasks and the pages that complete them, not around everything the company knows. We recommend testing it with a day-one account, because new hires have among the fewest permissions in the company and a demo run by the builder hides what they will actually see.

What a company brain is, and where onboarding breaks

The onboarding content usually exists already. The handbook links to a retired expense form, and the list of customer stories that are safe to share sits in a sales channel the new hire cannot open. The failures are in retrieval, ownership and access. A company brain gives employees one dependable way to find approved knowledge, see where an answer came from, and reach a person when the system cannot answer. The model is only the interface. A chatbot fed every document answers fast, and it can quote a stale policy, expose restricted material or state an unsupported answer with confidence, because it does not know which version of the expense policy is current, whether a draft compensation plan is confidential or which regional rule applies to this employee.

The brain has to do five things:

1. Name the source of truth for each topic.
2. Return answers that cite those sources.
3. Respect the employee's role and permissions.
4. Show who owns a page and when it was last reviewed.
5. Route unanswered or sensitive questions to a human.

The knowledge base, document storage, search, retrieval service, model and the interface in Slack, Teams or a browser all support this. None of them is the brain on its own.

How to onboard new employees faster with a company brain

Choose one cohort, such as customer-support hires in one region, and list the jobs they must finish in their first month:

• Find the current escalation policy.
• Explain the product's core concepts.
• Request access to support tools.
• Locate approved response templates.
• Identify the owner of an unusual customer question.
• Complete required reading and acknowledge it.

"Answer anything about the company" cannot be verified, and it pushes teams to ingest content before anyone has checked it. A job list can be tested, and every job without a page that settles it is a page to write before any model is involved. GitLab shows the shape in its onboarding handbook: each hire gets an issue, opened at least four days before the start date, with one main section of tasks due in 30 days and the role-specific tasks below it. Engineers have a different list, which how to onboard software engineers with a company brain covers. Then spread the cohort's first month across four moments:

• Before day one. Send logistics, a schedule and only what the person can access before employment begins. Keep the internal assistant away from personal accounts unless security has approved that flow.
• First day. Show how to inspect a citation, report a wrong answer and request missing access, and assign a short list of required pages instead of a library dump.
• First week. Surface role-specific tasks and reference material at the point of work. The Kipwise onboarding solution illustrates this combination of searchable knowledge, assigned reading, and workflows that reduce repeated manager questions.
• First month. Review unanswered searches, low-confidence answers, stale citations and repeated escalations, and give each gap to a content owner. Track whether it closes.

Build the pages before the model

Before connecting a model, inventory the sources the cohort already uses. For each one, record the system, topic, audience, owner, review date, sensitivity and canonical URL. If two documents claim to be authoritative, settle it yourself instead of asking AI to choose. A spreadsheet is enough for the inventory. The ownership decision is the point: every high-impact topic gets one canonical source and a named person or team who keeps it current.

An internal knowledge base is a practical home for policies, procedures, role guides, FAQs, and decision records that employees should be able to retrieve. Structure the content around questions and tasks instead of department charts: "How do I escalate a refund request?" is easier for a new hire to use than "Customer Operations Resources."

Clean the material before you index it. Archive superseded pages, label regional variations, add missing owners, and split documents that mix public and restricted information. AI will not repair contradictory sources, and it makes the contradiction faster to find.

A platform such as Kipwise's company wiki can provide the maintained source layer, search, review workflows, and knowledge-gap signals. If you later add a conversational assistant, keep the wiki or equivalent repository as the authority. The generated answer should point back to it.

Retrieval: quote policy, summarize procedure

Connect the cleaned pages through retrieval-augmented generation, usually shortened to RAG. AWS's explanation has the model consult your own vetted documents before it answers, instead of retraining it on them. For onboarding, that means you fix a wrong answer by fixing a page.

We recommend splitting answers by content type. For policy, such as expense limits, leave and security rules, have the assistant quote the governing sentence with the page link, the owner and the review date, and not paraphrase it. A paraphrase that turns "up to $75 a day for meals" into "about $75" is the version a new hire acts on. For procedure, such as setting up the VPN, a generated summary is fine, because the hire can check each step against the screen in front of them.

Write the answer contract before tuning any prompt. The assistant should:

• Answer only from retrieved, authorized sources.
• Cite the page behind each material claim.
• Say when the evidence is missing or contradictory.
• Prefer the current canonical page over an older duplicate.
• Show the content owner and review date when freshness matters.
• Escalate legal, employment, security and compensation decisions to a person (how to add human escalation).

When retrieval returns weak evidence, "I could not find an approved answer; ask People Operations in this channel" is a successful outcome. It protects the employee and exposes a gap the company can fix. Chunking matters too: break long manuals into coherent sections, but keep the page title, topic, region, department, owner, review date and sensitivity on every chunk, and test with the phrases new hires actually use, such as acronyms, old product names and misspellings.

Filter by permission before retrieval, and test as a day-one hire

Permission checks have to run before a passage reaches the model, not after it has written a response. In Azure AI Search, for instance, the security-filter option has the application pass the caller's user or group identity as a string, and the filter excludes every document that does not match. For content with access-control lists, Microsoft advises granting access to groups and not to individual users because groups are easier to manage. The rule is the same inside Slack or another chat tool: access to the bot is not access to every document the bot knows about.

Copying documents into an index also drops the permissions they inherited. In Google Cloud's IAM model, what someone can reach is the union of the policies on a resource and on its parent containers, which Google calls the effective allow policy. Files in a shared Drive folder or a SharePoint library inherit access from above in the same way. Index each document's effective permissions, not only what is set on the file, or check the source system when the question arrives.

Then test with a day-one account, not your own. A new hire's access grows over the first days: in GitLab's handbook, hires get baseline entitlements through the onboarding issue, and an access request for the role is generated on day 2, if a template exists for it. On day one that hire can open far fewer sources than the builder tested, and a permission-aware assistant will rightly decline to use the rest. Build the first-week answers from pages every employee can open, list the topics that must wait for access, and have the assistant name the missing access instead of saying "not found", so a pending permission is not mistaken for a knowledge gap.

Who owns it after the pilot

The fastest way to lose trust is to let the assistant cite an obsolete policy, so every canonical page needs an owner and a review expectation. Security, payroll, benefits and compliance pages need frequent review. Stable product history does not.

Put a small operating group in charge, with People Operations, IT, security and the pilot department. They agree on:

• Which repositories may be indexed and which data classifications are excluded.
• How permissions are synchronized.
• Who reviews reported answers.
• How long prompts, retrieved passages and logs are kept.
• What triggers shutdown or rollback.
• How employees can see and challenge an answer's sources.

NIST's AI Risk Management Framework is voluntary, and the part to read for an assistant that writes answers is its Generative AI Profile (NIST-AI-600-1), which helps identify the risks specific to generative AI and proposes actions for them. Turn the risks you accept into tests and into the shutdown triggers above. Keep an audit trail of source changes and model configuration too: if an answer causes harm, you need to know which content, permissions, retrieval settings and model version produced it.

Measure outcomes and set the go/no-go line before launch

A high number of chat messages does not prove value. Measure three things. Answer quality: valid citations, unsupported-answer rate, permission-test failures and stale-source rate. Workflow: how long hires take to find approved answers, how many routine questions still reach managers, how often the assistant escalates correctly and how fast owners close reported gaps. Onboarding outcomes: time to complete role milestones, confidence in finding information and early error rates. Use the same cohort and milestone definitions before and after, and read the numbers by role and region, because an overall improvement can hide a poor experience for employees whose documents or permissions differ.

Any access-control failure blocks release. Set the thresholds before launch, for example zero permission leaks, citations on every policy answer, a defined maximum unsupported-answer rate and faster completion of three selected tasks.

A 30-day pilot

1. Week one: inventory and ownership. Pick the cohort, list its jobs, identify canonical pages, remove conflicts, assign owners and classify access.
2. Week two: retrieval and controls. Index the approved set, configure permission filters, set the answer contract and build a small evaluation set of expected sources and refusal cases.
3. Week three: testing. Run realistic questions from managers and recent hires through a day-one account. Record citation failures, missing pages, permission problems and needless escalations, and fix the pages before tuning prompts.
4. Week four: supervised pilot. Release to a small group with a visible feedback route and a human fallback, review logs daily, close the most frequent gaps and compare against the thresholds.

At the end, expand the cohort, improve the same workflow or stop, depending on whether answers were approved and permission-safe and saved time without weakening onboarding. This week, write the job list for one cohort and put next to each job the one page that settles it.