A standard employee checklist is a bad fit for intern onboarding. It can give an intern broad access, routine production work, and a pile of documents without defining what the placement should teach or who must supervise each risky step. An AI company brain can make that failure faster by turning every retrieved instruction into an apparent green light. A time-bounded workflow should tie knowledge, access, work, feedback, and offboarding to explicit learning objectives. The tests in this guide prove that the intern learned safely rather than merely completing tasks.
Why ordinary employee onboarding fails interns
An employee is usually hired to own ongoing outcomes. An internship is a limited placement with a learning purpose. Intern onboarding therefore has to prove that assigned work serves that purpose and stays within the placement boundary.
The U.S. Department of Labor internship fact sheet describes factors used to assess unpaid internships under federal law. Those factors include training similar to an educational environment, a connection to academic commitments, a duration limited to beneficial learning, and work that complements rather than displaces paid employees. The legal classification depends on the full circumstances, so a company brain must never decide whether a person qualifies as an intern. People Operations or counsel owns that decision.
Even for paid internships, define the educational purpose before assigning work. If the system begins with the employee template, several problems appear:
- The intern receives permissions based on a department label instead of the project.
- The manager assigns backlog work without connecting it to a learning objective.
- The assistant answers from documents that are irrelevant or restricted.
- Completed readings are mistaken for practical readiness.
- Access survives the placement because no authoritative end date controls it.
A maintained onboarding process needs named owners, explicit tasks, access requests, support routes, and manager involvement. The GitLab onboarding handbook is a useful practitioner example of that structure. An internship workflow needs the same operational clarity plus learning goals, closer supervision, and a fixed lifecycle boundary.
Define the internship contract before creating tasks
Start with a small control record. 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:00ZTreat each field as an input owned by a human or an authoritative system. The company brain may explain the record and use it to select content. It may not widen the project scope, appoint a different supervisor, extend the placement, or remove a prohibition.
The learning objectives should describe observable outcomes. “Learn the product” is not testable. “Use the approved rubric to evaluate ten synthetic search cases and explain two failures” gives the intern, supervisor, and system the same finish line.
Keep employment classification, compensation, academic credit, accommodations, and performance decisions outside this record unless the responsible team explicitly needs a safe status field. The assistant does not need private details to explain the next task.
Build a scoped knowledge view
The intern should not search the whole company brain merely because the interface makes broad search easy. Retrieval must enforce the same access decision as the source system.
Microsoft documents several approaches to document-level access control in Azure AI Search, including security filters, access control lists, role-based scopes, SharePoint permissions, and sensitivity labels. The specific platform can vary, but the rule is stable: filter candidate evidence before generation, not after the model has already seen it.
Create an internship knowledge collection with 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 should carry an owner, audience, effective date, review date, and source link. Add the project identifier and environment where appropriate. Retrieval should require both identity permission and placement scope.
Set an answer contract with three requirements. The assistant answers only when it can return an accessible source, identify the task environment, and name the accountable reviewer. If any element is missing, it routes the question to the supervisor or source owner. It 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 work from observation to reviewed action
Access alone does not create readiness. Build a capability ladder that controls what the intern can do and what evidence is required to advance.
Stage 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 identify the source owner. The supervisor checks the explanation, not just the link click.
Stage 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. Record the output, questions, and supervisor feedback.
Stage 3: perform a bounded staging task
Grant only the permissions needed for one task. Define the expected artifact, validation command, reviewer, rollback method, and stop conditions. The assistant can retrieve instructions and explain terms, but it cannot approve the result.
Stage 4: contribute through review
If the placement calls for production-related work, route every contribution through the normal accountable review path. For a code change, that may mean a pull request with tests and a maintainer. For documentation, it may mean a source owner approving the change. For analysis, it may mean a supervisor checking the data boundary and conclusion.
Do not make stage progression automatic. A quiz score, completed page, or model confidence value is weak evidence. The named supervisor should confirm that the intern can perform the task, explain the relevant boundary, recognize a failure, and ask for help at the right point.
Separate the supervisor, buddy, and assistant roles
An intern needs clear human ownership. A company brain can reduce repeated explanation, but it cannot carry employment accountability or provide all learning feedback.
Use three explicit roles:
* 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. “Ask someone” is not a fallback. Name the supervisor, source owner, service desk, or program contact and explain what information to include. If the supervisor is unavailable, the placement record must identify a delegate. Otherwise the task pauses.
The assistant should not summarize private supervisor notes back to the intern or turn the intern's questions into performance evidence. Keep service telemetry, learning artifacts, and employment records separate. Questions often reveal where documentation is weak, not whether the person asking is capable.
Add feedback without turning it into surveillance
Feedback should attach 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. If a task exposes a gap in the documentation, create a separate knowledge issue owned by the source owner. Do not silently edit the source from an AI summary.
The NIST AI Risk Management Framework organizes AI risk work around governance, context mapping, measurement, and management. Applied here, that means naming owners, documenting the placement context, testing the assistant against realistic intern tasks, and changing controls when evidence shows a failure. It does not mean collecting every interaction.
Handle failures with stop rules
Write the failure behavior before the first intern signs in.
The answer lacks an accessible source. Withhold the instruction and route the question to the source owner. Log the knowledge gap without copying unnecessary personal context.
Two sources conflict. Show that a conflict exists, identify both owners, and stop. The assistant must not choose the newer timestamp unless an approved precedence rule says that timestamps govern.
The requested action exceeds project scope. Refuse the action, explain the current 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 authorize the assistant to become the reviewer.
Sensitive data appears in a practice task. Stop processing, preserve only the evidence needed for incident handling, notify the responsible owner, and replace the exercise with synthetic data after review.
The placement date changes. Update the authoritative lifecycle record first. Recalculate assignments, calendar items, and expiry from that event. Do not extend access from a chat message.
Verify the complete internship loop
Run an end-to-end test before onboarding the intern. Use a test identity with the same groups and placement scope.
- Confirm the intern can open every cited onboarding source.
- Search for a restricted employee document and prove it is absent from retrieval.
- Ask an ambiguous project question and confirm the assistant escalates it.
- Complete a synthetic task and verify that only the supervisor can approve progression.
- Trigger a failed task and confirm the rollback and support route work.
- Change a source version and verify that the answer cites the current approved record.
- Move the placement end date in the lifecycle system and verify assignments and expiry update.
- Simulate the end date and prove knowledge, tool, and environment access are removed.
- Confirm that the completion summary contains learning artifacts and approvals, not raw chat history.
Existing guidance leaves the full lifecycle disconnected. Internship guidance explains educational purpose. Onboarding handbooks explain tasks and owners. Access documentation explains permission filters. AI risk guidance explains governance. This workflow joins those pieces into one control loop: learning objectives determine scoped knowledge, scoped knowledge supports staged work, humans review evidence, and the fixed placement boundary removes access.
Use this launch checklist
Before the placement starts, require a yes for each item:
* The authoritative record contains start and end dates. * People Operations has confirmed the worker process and classification outside the assistant. * The supervisor and delegate are named. * Three to five observable learning objectives are approved. * Every initial task maps to an objective, environment, source, and reviewer. * Retrieval uses the intern's identity and project scope. * Practice data is synthetic or explicitly approved. * Production actions are blocked until a human grants a specific capability. * Feedback records are visible to the intern and separate from private HR notes. * Failure routes have named owners. * Access expiry is automated from the authoritative end date. * The team has tested negative access and end-date removal with a test identity.
Create the placement control record first, then run the nine verification tests with a test identity. Do not invite the intern until the restricted-search test, supervisor approval path, and access-expiry test all pass.
References
* U.S. Department of Labor Fact Sheet 71 supports the distinction between an educational internship and ordinary employment work under the federal primary-beneficiary analysis. * GitLab onboarding handbook provides a maintained practitioner example of explicit onboarding tasks, managers, buddies, access requests, and support routes. * Microsoft document-level access control supports retrieval-time permission enforcement through filters, access control lists, roles, and source permissions. * NIST AI Risk Management Framework supports the governance, context, measurement, and management structure used for the assistant controls. * Kipwise employee onboarding provides the product context for searchable onboarding knowledge, assigned reading, and progress tracking.
