AI for a University Admissions Office: Applicants and Documents

An AI agent for a university admissions office answers routine applicant questions from approved sources and checks each application file against a requirements checklist. Anything uncertain goes to a named staff member. It does not admit, reject, rank or waive anything. Staff keep every decision, and the agent makes sure their time goes to complete files and to questions that need judgment.

Key takeaways

• The best first role is narrow: answer factual applicant questions and report what is missing from each file, nothing more.
• Completeness checking is about presence and form (is the transcript there, is it readable, is it the right type), never about merit or authenticity.
• Every answer should come from approved, current sources, and the agent should say so when it cannot find one.
• Approval boundaries must be written down: the agent can draft and flag, but only staff can decide, grant exceptions or contact an applicant about a status change.
• Applicant data is sensitive, so permissions, logging and review of the agent's work matter as much as the quality of its answers.

What can an admissions agent answer without risking a decision?

Most applicant messages are not decisions waiting to happen. They are questions the office has answered many times: which documents a program requires, how to submit a translated certificate, whether a deadline applies to international applicants, how to change a contact address, where to find the portal. These questions arrive in bursts, often outside office hours, and the people asking are anxious. A fast, accurate answer is a real service.

An agent can handle this layer when it is tied to the office's own published rules. The answer should be built from the current admissions policy, the program requirement pages and the office's own frequently asked questions, and it should name which source it used. If the sources conflict or are silent, the agent should not guess. It should tell the applicant that a staff member will reply and create a handoff with the question, the applicant's reference and the source it checked.

A simple split helps the team agree on scope before anything is built:

• Answer directly: published deadlines, required document lists, formatting rules, how to use the portal, office hours, where to send documents, what a status label means in general terms.
• Answer with a staff check: questions about equivalence of a foreign qualification, late submissions, changed circumstances, accommodations, and anything where the applicant describes a unique situation.
• Never answer: whether the applicant will be admitted, how their file compares with others, whether an exception will be granted, anything about scholarships or financial aid awards, and any request to reveal another person's information.

The third list matters most. An agent that sounds confident about a likelihood of admission creates an expectation the office may not be able to meet, and the applicant will remember the sentence rather than the caveat. The agent should be built to decline politely and route, using wording the office has approved.

The same discipline applies in other education settings. The boundaries described in AI agents for schools and administration carry over well, especially the idea that student data is handled on a need-to-know basis. For enrollment-led institutions with smaller teams, the language school playbook shows how the same pattern works for scheduling and renewals.

How does document completeness checking work?

A completeness check answers one question: does this file contain what the requirements say it should contain, in a usable form? It does not answer whether the applicant is qualified. Keeping those two questions apart is the central design choice.

The agent needs three inputs. First, a requirement set for each program and applicant type, written in plain structured form by the admissions team (for example, domestic undergraduate, international graduate, transfer). Second, the documents and form fields actually received. Third, the rules for what counts as acceptable form, such as legibility, language and date windows. With those, it can produce a status for each file: complete, incomplete with specific missing items, or needs staff review.

A practical checklist for what the agent verifies:

• The document type matches the requirement (a transcript, not a course list; a passport page, not a photo of a desk).
• The file opens, is legible and is not cut off or duplicated.
• The name and date of birth on the document are consistent with the application, flagged as a mismatch for staff rather than corrected.
• A translation is attached where the rules require one, and a certified copy where the rules require one.
• The document falls within any required date window or has not passed an expiry.
• Referee letters or third-party documents have arrived from the stated source, not merely been promised.
• Required form fields are filled and consistent with the uploaded documents.

What the agent should not do is equally important. It should not judge whether a document is genuine, whether a foreign grade meets a threshold, or whether a gap in a history is acceptable. When something looks unusual (an inconsistent name, a blurred seal, an unfamiliar issuing institution), the output is a flag with the reason, not a conclusion. The reviewer sees the file, the flag and the original document side by side.

This is the same pattern used wherever paperwork has to be complete before a decision. The import and export documents article describes how checking presence and consistency across document sets reduces back-and-forth without replacing the person who signs off.

What does this look like in practice? An illustrative scenario

This is an illustrative scenario, not a report of a real office.

An applicant to a graduate program writes late in the evening asking whether a scanned degree certificate in another language is acceptable. The agent finds the office's published rule that foreign-language documents need a translation, and replies with that rule, the accepted translation formats and the link to the upload page. It adds that equivalence of the qualification is assessed by staff and is not part of this check.

The next morning the applicant uploads the certificate and a translation. The agent checks the file against the requirement set for that program. The certificate is readable and the translation is attached, but the name on the translation spells the surname differently from the application form, and one referee letter has not arrived. The agent does not correct the name. It sends the applicant a message listing the missing letter and asking them to confirm the spelling they want on record, and it opens a task for the assigned officer showing the mismatch, both documents and the message sent.

The officer reviews the task, confirms the spelling with the applicant, updates the record and marks the file ready for academic review. The agent's role ended at a clear, documented handoff. Nothing about admission was said to the applicant, and every step is in a log the office can read.

Where do staff keep the decision, and what can go wrong?

The boundary should be explicit and short enough that every team member can recite it. A useful decision guide for what the agent may do alone and what needs a person:

• The agent may send: factual answers from approved sources, document reminders using approved templates, and acknowledgements of receipt.
• The agent may prepare, but staff must approve before sending: any message that changes or interprets a status, any reply to a complaint or a sensitive personal circumstance, any message to a third party such as a referee beyond the standard reminder.
• Staff only: admit, reject, waitlist, rank, grant exceptions, accept or reject equivalence, extend a deadline, handle appeals, and verify authenticity.
• Always escalate: mentions of disability, health, immigration difficulty, financial hardship, safety concerns, legal threats or discrimination.

Three risks deserve attention in the design rather than after launch.

The first is manipulated content. Applicants upload files and write free text, and a document can contain text that tries to instruct the agent (for example, to mark a file complete or to reveal other records). The [OWASP guidance on prompt injection prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) describes the defenses: treat uploaded content as data and never as instructions, limit what tools the agent can call, and validate outputs. In an admissions setting this means the agent cannot change a final status field at all, so there is nothing for an injected instruction to unlock.

The second is access. The agent should see only the files and fields it needs, and should be able to act only through narrow tools, such as creating a task or sending an approved template. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) on least privilege and deny-by-default applies directly. An applicant asking about their own file must be verified before the agent shows anything, and the agent must never reveal information about another applicant.

The third is regulatory and fairness exposure. Rules vary by country, but systems used to decide access to education are treated as high risk in the [EU AI Act](https://artificialintelligenceact.eu/) overview, and data protection law governs applicant records almost everywhere. Keeping the agent out of evaluation and ranking is both the safer design and the simpler one to defend. A governance frame such as the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) helps the office document who owns which risk, how performance is measured and when the system is paused. Your legal or compliance lead should confirm the specifics for your jurisdiction. For the evidence and review habits that support this, see AI for compliance teams.

How should an admissions office start?

A first engagement should be small enough to finish and observable enough to judge. A step-by-step plan:

• Choose one applicant group and one stage, for example international graduate applicants during document collection.
• Write the requirement set for that group in structured form, with the admissions lead owning every line.
• Collect the real questions applicants ask, from email, chat and phone notes, and sort them into answer directly, answer with a check, and never answer.
• Identify the approved sources for each answer, and retire or fix any that are outdated or contradictory before the agent reads them.
• Define the handoff: who receives flagged files, what the task contains, and how quickly each type should be picked up.
• Set the approval boundaries in writing, including the staff-only list above, and make them technical limits rather than instructions alone.
• Run the agent in shadow mode first, producing drafts and statuses that staff compare with their own, before it contacts any applicant.
• Define a success criterion that staff can observe, such as fewer files reaching review with avoidable missing items, and faster first replies to routine questions.
• Review a sample of conversations and file checks on a regular schedule, and record every change to the rules.

The order matters. Teams often start with the chat window and discover that the real source of confusion is an outdated requirements page. Fixing the sources first makes every later step more reliable.

How does Be Human handle this?

Be Human designs, implements and operates the agent as part of the office's own infrastructure. A first engagement defines one role (for example, applicant questions and completeness checks for one group), the memory and tools it needs, the approval boundaries and a success criterion the team can observe. The agent keeps its identity, channels and operating context under the office's control, with permissions limited to the tools the role requires. Managed operations can include monitoring, recurring evaluations against real applicant questions, integration maintenance, permission review, incident response and controlled improvements when requirements change between intakes.

Frequently asked questions

Can the agent tell an applicant that they have been admitted or rejected? No. Decisions are made and communicated by staff using the office's own process. The agent can confirm that a file is complete and explain, in general terms, what the next stage is, but it cannot state or imply an outcome.

What happens when the agent does not know the answer? It says so, tells the applicant that a staff member will reply, and creates a handoff containing the question, the applicant reference and the sources it checked. This is a designed behavior, and reviewing these handoffs is one of the best ways to find gaps in the published requirements.

How do we keep applicant data safe? Start by limiting what the agent can see and do: verified access to an applicant's own file only, narrow tools, no ability to change decision fields, and a log of every action. Add a review of permissions and sampled conversations on a schedule, and confirm retention and consent rules with your data protection lead.

Does the agent replace admissions staff? No. It removes repetitive questions and the first pass of checking for missing items, so officers spend more time on files that need judgment and on applicants who need a human conversation. Staff still own every decision, exception and appeal.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.