What Should a Leader Ask Before Introducing an AI-Based Administrative Assistant at Their University?

1. Who is the data controller, and what actually happens to the data?

This is one of the most important, yet most frequently superficially handled, questions. An AI assistant must legally and unambiguously function as a data processor. The data controller always remains the institution; the system may only process data on the institution's behalf, for purposes set out in the contract.

Questions worth asking:

• Is conversation data used for model training, whether for the provider's own benefit or that of other institutions?
• Where is the data stored, in which country, on what infrastructure?
• Does the provider have a data processing agreement (DPA), and what exactly does it specify?
• Can the institution export, delete, and audit its data at any time?

2. How can you know a given answer is correct?

The usefulness of an AI assistant does not hinge on the speed of its answers, but on their reliability. According to our own research, this is the single greatest concern for 83.8% of higher education professionals regarding an AI-based solution, and rightly so.

Questions worth asking:

• Does every answer come with source citations, so a student or staff member can verify it?
• Does the system rely exclusively on the institution's own, official content, or does it supplement answers from elsewhere?
• Is there a way to restrict the topics the system answers, so it doesn't comment on certain sensitive or legal matters?

3. What happens if the system cannot answer the question?

A well-designed system does not promise to answer everything. It promises to clearly recognize when a question requires a human administrator, and to handle the handoff properly.

Questions worth asking:

• Is escalation automatic, or does the student have to repeat their question to a human administrator?
• Does the administrator receive the full conversation history, or do they have to start from scratch?
• Is there a trackable, auditable process ensuring an escalated case is actually answered?

4. What integration burden does this place on the institution's IT team?

This is the consideration most frequently underestimated when planning implementation. Not every integration is equally difficult, so it's worth clarifying early in discussions what counts as a quick integration and what counts as one that takes months.

Questions worth asking:

• Which systems, for example the student information system, LMS, or email, require genuine, institutional IT involvement, and which require only a simple, independently completable step?
• Is there a realistic, phased timeline, or a vague promise of being live within a month?
• Who bears responsibility if an integration slips due to the institution's own system's peculiarities?

5. Can the system be verified before commitment, without obligation?

A well-founded decision requires more than a demo video or a reference list. It's worth insisting that the system prove itself on the institution's own, specific questions before any commitment is made.

Questions worth asking:

• Is there an opportunity for the institution to submit its own real questions for testing, and see the actual answers?
• Is this test free and without obligation, or does it already involve a payment commitment?
• Based on the test result, does the institution receive documented, comparable feedback, for example on strengths, weaknesses, or expected accuracy level?

6. Is the pricing transparent, and what happens under extreme load?

If pricing is usage-based, it's worth clarifying in advance what happens if the system, whether for benign or malicious reasons, suddenly receives a large volume of inquiries.

Questions worth asking:

• Is there protection against abusive, automated traffic, which would inevitably occur with a publicly accessible system?
• If such abuse does occur, who bears the cost, the institution or the provider?
• Is there an optional, pre-set cost cap above which the system automatically alerts?

Why is it worth thinking through these six considerations together?

No single consideration is sufficient on its own. A technically excellent but non-transparent data-handling system carries legal risk. A legally sound but inaccurate system erodes trust. An accurate but untestable system represents unnecessary risk in a long-term contract. Together, these six considerations give a leader a picture on which they can base a well-founded decision, and one they can use to justify that decision to their own legal or IT department.

If you would like to work through these six considerations as applied to your own institution, or learn how Emily answers these questions, feel free to reach out to us.