◇ OpenCyber Academy
Engineering · Chapter 43 · English

Chapter 43 — Industry or public-service practice

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 43 — Industry or public-service practice

Lesson map

Lesson 43 published. Map, example, EX127.

flowchart TD
  N0["Learning outcomes"]
  N1["43.1 Placement goals"]
  N2["43.2 Governance in practice"]
  N3["43.3 Authorised work only"]
  N4["43.4 Reflective practice"]
  N5["43.4b Working with constraints"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX127"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["43.1 Placement goals"]
  N2["43.2 Governance in practice"]
  N3["43.3 Authorised work only"]
  N4["43.4 Reflective practice"]
  N5["43.4b Working with constraints"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX127"]

[Learning outcomes]
    |
    v
[43.1 Placement goals]
    |
    v
[43.2 Governance in practice]
    |
    v
[43.3 Authorised work only]
    |
    v
[43.4 Reflective practice]
    |
    v
[43.4b Working with constraints]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX127]

Learning outcomes

You will (1) work within an organisation's AI governance and security processes; (2) contribute to real (authorised) AI-security tasks under supervision; (3) reflect on practice using evidence; and (4) maintain professional confidentiality and ethics during placement.

43.1 Placement goals

A placement connects coursework with organisational reality: budgets, deadlines, legacy systems, procurement and regulation. Agree goals with the host and the university: typically one deliverable (an assessment, a control implementation, an evaluation suite) plus participation in routine processes.

One deliverable gives the placement a clear purpose and something the host can keep using; joining routine processes, such as change boards or incident reviews, shows how decisions are actually made. Goals are written down in the first week with the host supervisor and the academic tutor, so all three agree what success looks like and what the student may access.

43.2 Governance in practice

Organisations adopting ISO/IEC 42001 or the NIST AI RMF have AI policies, inventories, risk assessments and approval boards. Learn how an AI system is proposed, assessed, approved and monitored, who signs off and what evidence they expect.

Watching a real approval shows what the frameworks look like in daily use. A board may ask for a risk assessment, a model card and a test summary before approving a pilot, and for monitoring data before approving full use. Students learn which evidence decision-makers read and which they skip, which shapes how they write their own reports. They also see how long approval takes and plan their work around it.

43.3 Authorised work only

All testing on placement is governed by written authorization from the system owner, specifying scope, methods and time. Use non-production environments where possible. Report findings through the host's channels; never disclose them externally without permission.

Being on placement does not grant permission to test anything. The written authorization names the systems, the methods and the dates, and a student who finds an interesting system outside it asks before touching it. Non-production environments protect the host's operations and the student, since an accidental outage caused during testing can end a placement. Findings belong to the host, who decides how and whether they are shared.

43.4 Reflective practice

Keep a weekly log: what you did, what evidence you produced, what surprised you, what you would do differently. Reflection turns experience into transferable skill and is assessed.

A useful entry goes beyond 'I reviewed the inventory'. It notes what was hard, for example that business owners did not know whether their spreadsheet tools counted as AI, and what the student would change next time, such as asking about add-ins explicitly. Reading entries back at the end shows patterns that single weeks hide, and gives concrete examples for job interviews and later assessments.

43.4b Working with constraints

Real organisations rarely start from a clean design. Legacy systems lack logs, vendors limit testing, budgets are fixed and deadlines move. Good practitioners prioritise by risk, propose the smallest control that meaningfully reduces it, and document what remains. A short, accurate risk note delivered on time is usually more valuable than a perfect assessment delivered after the decision.

Sam's placement shows this. The three spreadsheets with ML add-ins had no logs and no owner on record, so the inventory entered them with an "unknown" data sensitivity and a named person to confirm it, rather than leaving them out until they could be assessed fully.

43.5 Worked example (synthetic NRS case)

Sam's placement goal was to build the AI inventory for NRS. Using the inventory lab as a starting template, Sam catalogued 14 AI systems, including three spreadsheets with embedded ML add-ins nobody had registered. The inventory scored exposure, autonomy, data sensitivity and untrusted input; the CV-screening pilot in HR scored high and was sent for a fuller assessment, partly because recruitment systems can be high-risk under the EU AI Act.

"""Lab V: an AI system inventory scored for review priority (synthetic).
Each system lists exposure, autonomy, data sensitivity and whether it reads
untrusted content; mapping to OWASP LLM Top 10 (2025) IDs is illustrative."""
import json
inv = json.loads("""[
 {"name":"support-chatbot","exposure":"public","autonomy":"tools","data":"customer","untrusted_input":true},
 {"name":"invoice-ocr-model","exposure":"internal","autonomy":"none","data":"financial","untrusted_input":true},
 {"name":"code-assistant","exposure":"internal","autonomy":"suggest","data":"source","untrusted_input":true},
 {"name":"churn-predictor","exposure":"internal","autonomy":"none","data":"customer","untrusted_input":false},
 {"name":"hr-cv-screener","exposure":"internal","autonomy":"decide","data":"personal","untrusted_input":true}
]""")
E = {"public": 3, "internal": 1}; A = {"none": 0, "suggest": 1, "tools": 3, "decide": 3}
D = {"customer": 2, "financial": 2, "source": 2, "personal": 3}
for s in inv:
    s["score"] = E[s["exposure"]] + A[s["autonomy"]] + D[s["data"]] + (2 if s["untrusted_input"] else 0)
    risks = []
    if s["untrusted_input"]: risks.append("LLM01")
    if s["autonomy"] in ("tools", "decide"): risks.append("LLM06")
    if s["data"] in ("customer", "personal"): risks.append("LLM02")
    s["owasp"] = ",".join(risks) or "-"
for s in sorted(inv, key=lambda s: -s["score"]):
    print(f"{s['name']:18s} score={s['score']:2d} owasp={s['owasp']}")

Expected output:

support-chatbot    score=10 owasp=LLM01,LLM06,LLM02
hr-cv-screener     score= 9 owasp=LLM01,LLM06,LLM02
code-assistant     score= 6 owasp=LLM01
invoice-ocr-model  score= 5 owasp=LLM01
churn-predictor    score= 3 owasp=LLM02

The lab's scoring explains the result: autonomy to decide, personal data and untrusted CVs put the screener near the top of the list.

43.6 Errors and limits

Testing beyond scope is the most serious, because good intentions do not make unauthorised access lawful or safe. Deliverables that rely on the student to maintain them stop working when the placement ends, so handover to a named owner is part of the work. Logs that only list tasks miss the learning the assessment is looking for: what changed in the student's understanding and why it changed.

Exercises

Synthesis

Practice reveals how AI security works inside organisations: governance processes, authorised work, real constraints and the habit of reflective improvement.

Continue studying — chapter 43 of 50

← Chapter 42 (draft) · Course chapter index · Chapter 44 (draft) →