How to Onboard Interns with an AI Company Brain

Do not start an intern from the employee onboarding template. An internship is a time-boxed placement with a learning purpose, so tie the assistant's knowledge, the intern's access and the work to one placement record with an end date, and treat a stage as passed only when the intern shows the skill with the assistant closed. We recommend this because an assistant that answers every question makes completed tasks look like learning, and an employee role leaves access in place after the placement ends.

Why the employee template fails interns

An employee is usually hired to own ongoing outcomes. An internship is a limited placement, so onboarding has to show that the assigned work serves the learning purpose and stays inside the placement boundary. The U.S. Department of Labor internship fact sheet covers interns at for-profit employers and describes the seven-factor primary beneficiary test that courts use for unpaid interns, a flexible test in which no single factor is determinative. Two of the factors bear directly on the assistant: the training should resemble an educational environment, and the work should complement rather than displace paid employees. Classification depends on the circumstances of each case, so the company brain must never decide whether someone qualifies as an intern. People Operations or counsel owns that decision.

Even for paid internships, define the educational purpose before assigning work. Starting from the employee template causes five problems:

1. The intern receives permissions based on a department label instead of the project.
2. The manager assigns backlog work without connecting it to a learning objective.
3. The assistant answers from documents that are irrelevant or restricted.
4. Completed readings are mistaken for practical readiness.
5. Access survives the placement because no authoritative end date controls it.

GitLab's onboarding handbook shows the same instinct: its list of onboarding issue templates puts an intern template next to the one for all team members. An internship workflow needs that kind of operational clarity plus learning goals, closer supervision and a fixed lifecycle boundary.

Write the placement record before the first task

Before any AI control, the ordinary internship checklist still has to be done: a written offer with dates and pay status, paperwork and eligibility checked by People Operations, a named supervisor and delegate, a buddy, and a first project with its objectives written down. Turn those into a small control record, and do not ask the model to infer it from an offer letter, a manager message or a calendar invitation.

placement_id: int-2026-042
worker_id: usr-1842
start_date: 2026-09-14
end_date: 2026-12-18
program_owner: people-ops-internships
supervisor: mgr-077
project_scope:
 - customer-help-search-evaluation
learning_objectives:
 - explain the search evaluation rubric
 - run a test set without customer data
 - present findings with cited evidence
allowed_environments:
 - training
 - staging-read-only
production_actions: prohibited
review_cadence: weekly
access_expiry: 2026-12-18T18:00:00Z

Each field is owned by a human or an authoritative system. The company brain may explain the record and use it to select content, but it may not widen the project scope, appoint a different supervisor, extend the placement or lift a prohibition. Keep employment classification, compensation, academic credit, accommodations and performance decisions out of the record unless the responsible team needs a safe status field. The assistant does not need private details to explain the next task.

Write the objectives as observable outcomes. "Learn the product" cannot be tested. "Use the approved rubric to evaluate ten synthetic search cases and explain two failures" gives the intern, the supervisor and the system the same finish line. Set the midpoint and final expectations the same way.

Scope what the assistant can see

The intern should not search the whole company brain just because the interface makes broad search easy. Retrieval has to enforce the same access decision as the source system, before generation and not after the model has seen the evidence. In Azure AI Search, for example, a security filter compares the caller's user or group identity with the identities stored on each document, so the groups you give the intern decide what is retrievable. Give the intern the project group and the cohort group, not the department group.

Build the internship knowledge collection in four layers:

• Program basics: conduct, communication norms, support routes, required training and schedule.
• Project context: approved goals, glossary, architecture overview, source owners and current decisions.
• Task instructions: the exact procedure, safe environment, expected output, reviewer and rollback path.
• Reference evidence: source passages the intern can open with their own identity.

Every record carries an owner, audience, effective date, review date and source link, plus the project identifier and environment where they apply, and retrieval requires both identity permission and placement scope. The assistant answers only when it can return an accessible source, identify the task environment and name the accountable reviewer. If any of the three is missing, it routes the question to the supervisor or the source owner and does not fill the gap with a plausible procedure.

Kipwise describes employee onboarding through shared knowledge and assigned reading. For an intern, assigned knowledge must follow the placement contract rather than the broad employee role.

Stage the work, and check each stage with the assistant closed

Access alone does not create readiness. A capability ladder controls what the intern may do and what evidence moves them up:

1. Orient and observe. Give the intern the program basics, project map, terminology and safe support routes. Ask them to trace one realistic question to the approved source and name the source owner. The supervisor checks the explanation, not the link click.
2. Practice with synthetic inputs. Use fabricated records or a purpose-built training environment. The intern follows the real procedure without customer data, credentials, financial impact or production side effects, and the supervisor reviews the output and the questions asked.
3. Perform a bounded staging task. Grant only the permissions one task needs, and define the expected artifact, validation command, reviewer, rollback method and stop conditions. The assistant retrieves instructions and explains terms. It cannot approve the result.
4. Contribute through review. If the placement includes production-related work, route every contribution through the normal accountable review: a pull request with tests and a maintainer for code, a source owner for documentation, a supervisor checking the data boundary and the conclusion for analysis.

Do not make progression automatic. A quiz score, a completed page or a model confidence value is weak evidence. We recommend checking each stage with the assistant closed. The assistant may teach: it finds the source, explains a term and checks a draft against the rubric. But an artifact produced with it open shows that the intern can use the assistant, not that the intern can do the task. At the end of each stage, ask the intern to explain or redo a small piece without it, with the supervisor watching, and let that decide whether the intern moves up. The supervisor also confirms that the intern can recognize a failure and knows when to ask for help.

Supervisor, buddy and assistant

An intern needs clear human ownership. A company brain reduces repeated explanation, but it cannot carry employment accountability or all of the learning feedback.

• The supervisor owns objectives, work selection, access requests, feedback and progression.
• The buddy helps with team habits, navigation and low-stakes questions but does not approve consequential work.
• The assistant retrieves approved knowledge, records unresolved questions and points to the correct human route.

Show the role next to every task, and name the supervisor, source owner, service desk or program contact instead of writing "ask someone", with what to include in the message. The placement record must name a delegate for when the supervisor is away, or the task pauses. The assistant should not summarize private supervisor notes back to the intern or turn the intern's questions into performance evidence. Questions usually show where documentation is weak, not whether the person asking is capable.

Feedback without surveillance

Attach feedback to defined work and learning objectives. Avoid passive scoring based on chat volume, response speed, browsing behavior or how often the intern asks for help. For each reviewed task, capture only what the learning loop needs:

{
 "objective": "run the approved search evaluation",
 "artifact": "evaluation/int-2026-042/week-2",
 "reviewer": "mgr-077",
 "result": "revise",
 "feedback": [
 "Cite the rubric version used",
 "Separate retrieval errors from ranking errors"
 ],
 "next_task": "repeat with five new synthetic cases"
}

The intern should be able to inspect this record and correct factual errors. Keep subjective employment notes in the authorized HR process, not in the searchable knowledge layer.

When a task exposes a gap in the documentation, open a knowledge issue owned by the source owner, and never edit the source from an AI summary. We recommend that the intern drafts the fix. An intern who just failed to find the answer is the best-placed reader to write it, the draft is a visible learning artifact, and the owner's approval keeps the page under human control. Count the accepted fixes toward the objectives, not the number of questions asked.

NIST states the aim of its AI Risk Management Framework as managing risks to individuals, organizations and society from AI. In an internship the individual at risk is the intern, whose questions, mistakes and learning artifacts would be the data, so most of the controls are about what you do not collect. Name owners, document the placement context, test the assistant against realistic intern tasks and change the controls when the evidence shows a failure.

Stop rules

Write the failure behavior before the first intern signs in.

• The answer lacks an accessible source. Withhold the instruction, route the question to the source owner and log the knowledge gap without copying personal context.
• Two sources conflict. Show that a conflict exists, name both owners and stop. The assistant must not choose the newer timestamp unless an approved precedence rule says timestamps govern.
• The requested action exceeds project scope. Refuse, explain the boundary and send an access request to the supervisor. Never grant access because a task description mentions the system.
• The supervisor is unavailable. Use the recorded delegate or pause the task. A deadline does not make the assistant the reviewer.
• Sensitive data appears in a practice task. Stop processing, keep only the evidence incident handling needs, notify the responsible owner, and replace the exercise with synthetic data after review.
• The placement date changes. Update the authoritative lifecycle record first, then recalculate assignments, calendar items and expiry from it. Do not extend access from a chat message.

Test the whole placement before the intern starts

Use a test identity with the same groups and placement scope, and check that:

1. The intern can open every cited onboarding source.
2. A restricted employee document is absent from retrieval.
3. An ambiguous project question is escalated.
4. Only the supervisor can approve progression after a synthetic task.
5. A failed task triggers the rollback and the support route.
6. A changed source version produces an answer that cites the current approved record.
7. Moving the placement end date in the lifecycle system updates assignments and expiry.
8. Simulating the end date removes knowledge, tool and environment access.
9. The completion summary contains learning artifacts and approvals, not raw chat history.

Create the placement record first, then run the nine tests. Do not invite the intern until the restricted-search test, the supervisor approval path and the access-expiry test all pass.