AI Coding Policies for HBO-ICT Programmes: Who Decides What?

Keep policy, guidance, instructions and procedure distinct

Policy sets requirements, permissions, prohibitions, responsibilities and decision rights. Guidance helps people apply those rules in practical situations. Course or assessment instructions state the condition for a particular learning activity or assessment. Institutional procedure handles formal matters such as suspected breaches, appeals, sanctions or security incidents. These documents can refer to one another; a programme policy should not pretend to replace them all.

Make the layers and precedence understandable

Institution-wide requirements may cover approved systems, procurement, information security, data handling and formal procedures. Programme rules can set educational defaults, shared terminology, disclosure expectations and common student and staff responsibilities. Course guidance explains how those defaults apply in that course. Assessment instructions state the permitted, restricted or prohibited use for that particular task, including any disclosure or evidence requirement.

This is a practical way to organize rules, not a legally fixed Dutch hierarchy. The programme should state which rules apply by default, who is authorized to set different assessment conditions, whether a task may narrow the default, and what students should do if instructions conflict. Give them a named route for clarification before work or submission; do not expect them to guess which document takes precedence. For how those conditions connect to programme learning claims, see Assessment Integrity; for alignment within one assignment, see Assignment Assessment.

Write rules people can apply

Brainstorming, explanations, code suggestions, implementation, debugging, test generation, refactoring and documentation are different uses. A programme may distinguish permitted, restricted and prohibited use, but the condition depends on the learning outcome, assessment purpose and institutional tool or data constraints. “AI allowed” and “AI prohibited” are not sufficiently specific when staff and students need to know what to do.

“AI may support but not replace your own work” leaves “replace” undefined. For a particular task, a clearer instruction might say which uses are allowed, which assessed work must be completed without generated implementation, what material use must be disclosed, what verification is required, and where to ask if unsure. Likewise, “all AI use must be documented” should be replaced by a defined disclosure scope and minimum information—for example, whether routine built-in autocomplete is excluded. These are wording examples, not policy clauses for every course.

Separate tool approval from educational permission

Institutional approval may concern procurement, accounts, support, information security or data handling. Educational permission concerns whether a particular use is allowed in a learning activity or assessment. An approved tool is not automatically allowed for every task; an educationally relevant use does not automatically clear any external tool for institutional or project data.

A named-tool rule can aid clarity and support, but may become stale or hide differences between tiers and model capabilities. A use- or capability-based rule may connect more directly to learning purpose, but can be ambiguous and still needs institutional tool and data constraints. Some programmes may combine the approaches; there is no universally best choice. Students and staff should follow applicable institutional, client, internship and project requirements before submitting protected or confidential material to an external AI service. Passwords, API keys, access tokens and private credentials should not be entered into AI systems unless an explicitly approved workflow allows it. See SURF’s AI information-security guidance and OWASP’s Secure Coding with AI guidance for their respective scopes; neither resolves local data-policy or legal questions.

Constructed example: one programme, two assessment conditions

Constructed example — not institutional policy, legal advice or TraceYield policy. A second-year HBO-ICT Web Development module follows an institution’s tool, data and security requirements and its formal misconduct procedure. The programme sets an educational default: AI may be used for formative work subject to those institutional rules. Assessment instructions specify when that default changes.

Assessment A permits AI implementation assistance and states what material use students must disclose and what they must verify. Assessment B restricts AI during one controlled component because unaided performance is part of the learning outcome. A student who cannot access a named tool or is unsure whether a new use is permitted has a stated clarification route and an identified exception owner. If a student asks whether client code can go to an external service, the lecturer refers to the applicable institutional, client or project data rule rather than improvising an answer. This arrangement is an example, not a mandatory policy structure.

Give students and staff clear responsibilities

Students need to know the applicable condition, follow tool and data restrictions, make required disclosures, retain only evidence explicitly requested, verify output where the learning outcome requires it, and ask before submission if a use is unclear. Disclosure scope belongs in programme policy; the separate Student Disclosure guide discusses the student-facing question in more detail.

Staff need to state conditions clearly, use shared terminology, avoid conflicting instructions, explain disclosure and evidence expectations, keep materials current, and route suspected breaches through the appropriate institutional process. A detector flag is not a verdict; see AI Detection.

Plan a route for exceptions and access differences

The policy should identify where to ask when a named tool is unavailable, an account or usage limit blocks access, an internship or client condition differs, a student needs an accessibility accommodation, or a novel use is not covered. Identify the person or institutional route that can clarify or decide; do not leave exceptions to improvised case-by-case answers with no owner.

If AI use is required or assessed, consider material differences in model capability, account tiers, limits, hardware, institutional support and accessibility. If AI is optional, consider whether students have a viable alternative way to demonstrate the same outcome. These are practical design questions, not a promise of identical access or a legal conclusion.

Name the owner of each decision

The institution can identify institution-wide tool, data, security and formal-procedure requirements. The programme should name an owner for its educational default, shared terms, effective version and clarification route. A course coordinator can translate that default into course guidance; the lecturer or assessment team communicates the specific task condition. IT, security, procurement and accessibility colleagues answer questions within their remit. An examination or assessment-governance body may have a role under local arrangements. This is a governance-neutral way to assign work, not a statement of statutory authority.

The policy should say who may approve an exception, who resolves conflicting course and assessment instructions, and where a student asks about a novel use before submission. “Staff are responsible” is too broad to tell anyone who will act.

Cover staff use of AI as well as student use

At programme level, ask whether existing institutional rules cover staff use of AI to create assessment material, draft feedback or marking comments, analyze submissions, or upload student code, reports and reflections to an external tool. The programme should identify which approved conditions apply and where staff can get a decision; it should not make an informal privacy or legal determination itself.

Do not require full prompt histories or continuous activity records by default. Evidence collection should have a stated educational or institutional purpose, rather than being retained merely because a tool can capture it.

Separate a rule from evidence, procedure and sanction

A rule says what is permitted or prohibited. Evidence may indicate that a rule-relevant use occurred. A procedure describes how a concern is reviewed or escalated. A sanction is determined through the authorized institutional process. Do not let a detector signal stand in for a finding, or let a programme article invent evidentiary thresholds, investigation steps, appeal rights or sanctions. The Assessment Integrity guide addresses learning claims and evidence; formal misconduct handling remains with applicable institutional procedure.

Technical controls—such as blocked sites, disabled plugins, SSO restrictions, telemetry or approved-tool lists—can implement parts of an institution’s rules. They do not determine whether a policy is educationally appropriate. Telemetry does not automatically prove compliance, and inability to observe a use does not imply permission.

Version rules and state when they apply

Identify a policy owner, version, effective date, review trigger and communication route. Triggers may include an institutional rule change, a material tool or model change, assessment redesign, or a security or procurement change. No fixed annual cycle is needed; the point is to know who maintains the rule and how people learn that it changed.

State which version applies to work in progress and to a submitted assessment. Do not assess work against an AI rule introduced only after the relevant activity occurred. Communicate the effective date with the change so students and staff can identify the conditions that applied.

Use Dutch-sector guidance as context, not as a ready-made rulebook

Npuls’ Visietool Toetsen, published in 2026 for hbo and wo, supports multidisciplinary discussion and local choices about assessment and AI. Npuls describes the AI-waaier as a non-normative discussion aid developed with and for mbo, which may also be useful in hbo and wo; it is not an HBO-ICT standard. The HBO-i roundtable account reports a discussion among 13 lecturers from six hogescholen in 2024. It illustrates sector discussion, not national consensus or validated policy practice.

Use these sources to inform local discussion, then name the decision owner and the rule that students and staff should follow. Do not present a sector vision or discussion aid as binding policy.

Review whether the rules work in practice

After a course or assessment, course teams can note where students asked for clarification, where instructions conflicted, whether a tool or access condition changed, and whether staff applied the same rule. Use those observations to decide whether guidance needs revision; they do not prove that the policy caused a particular outcome.

Where relevant records are captured, TraceYield may provide context about work under stated assessment rules. It does not define policy, decide permitted use, approve tools, provide legal compliance, determine misconduct or sanctions, guarantee disclosure, enforce institutional rules or replace examination and assessment governance. The practical review question is whether students and staff could identify the applicable rule, its owner and the route for uncertainty.