Security by design, privacy by design and AI by design ask different questions of an AI system. They have to be answered at the same design gates, and a system built that way keeps its own evidence.
Willy Tai · Smart Cities · AI · ESG · October 2026
Three weeks before an AI assistant goes live, internal audit asks for four things: the pass marks agreed before testing began, the list of documents the assistant can retrieve from, the approval for the current system prompt, and a record of what the assistant told users last Tuesday. The pass marks were chosen after the results came in. The document list has to be rebuilt from a shared drive. Nobody approved any of the many versions of the system prompt. Last Tuesday is gone, because nobody decided to keep it.
Each gap goes back to a decision nobody made at design time. Security, privacy and AI governance each have a "by design" tradition, and each would have closed part of it. The three ask different questions of a system and have to answer them at the same design gates. Built that way, a system writes its own evidence as it runs, and assurance becomes the reading of records that already exist.
The oldest of the three is security by design. CISA and its international partners ask software makers to own their customers' security outcomes [1]. The UK NCSC and CISA, with partners including Singapore's Cyber Security Agency (CSA), carried the idea across the AI lifecycle [2], and CSA's own guidelines, written for the organisation adopting AI, run from planning to end of life [3]. The question security asks is who could make the system do something its owner never intended.
Privacy by design asks whether the data should be collected or used at all, for what purpose and for how long. Ann Cavoukian made privacy the default setting, so protection holds even if the individual does nothing [4], and Article 25 of the GDPR made that law [5]. My piece on ISO 42001 filed access to training data under confidentiality, which was incomplete: confidentiality asks who can read the data, and privacy asks whether it should be there in the first place.
AI by design is the least settled term. I use it for the controls specific to AI that neither security nor privacy supplies, designed in from the first decision: purpose and potential harm, data that represents the cases the system will meet, testing against a yardstick fixed in advance, explanation, a person able to override or stop the system, drift monitoring and a record of who decided what. The frameworks draw this boundary themselves. CSA's security guidelines put fairness, transparency and safety outside their scope [3]. NIST lists risks that are new or worse in AI, among them harmful bias and data drift, and says existing frameworks and guidance cannot adequately manage harmful bias or fully address attacks specific to machine learning [6]. Singapore's Model AI Governance Framework and AI Verify, ISO/IEC 42001 and the EU AI Act's high-risk requirements each fill that space [7][8][9][10]. The architectural half of this argument is in The trust boundary.
Take an estate operator in Singapore that wants a helpdesk assistant for staff and residents. It retrieves from maintenance records, service contracts, contractor reports and past complaint tickets, drafts an answer that cites its sources, and can draft a work order for a supervisor. The tickets hold names, unit numbers and phone numbers, and sometimes more. A resident who mentions a wheelchair in a lift complaint has disclosed something about their health.
At the idea gate, the first question is how much harm a wrong answer could do. Singapore's framework uses a probability and severity matrix to decide how closely a person stays involved [7]. The yardstick belongs here too. The EU AI Act tests high-risk systems against metrics and thresholds defined in advance [10], and MAS's guidelines, issued on 7 October 2026, expect residual risk to sit within appetite before deployment [12]. Only a threshold set now can show whether what the log later records was acceptable. Privacy needs the purpose pinned down, because the PDPC expects a deployer to keep the system away from data outside it [11], and security needs a threat model.
The data gate turns on where personal data will sit. The PDPC accepts that removing specific information from inside a model is hard today, and gives a retrieval database as a place where acting on a correction request is reasonable [11]. Poisoning can enter through embeddings as well as training, so security needs the origin of each document [13]. The AI question is whether the stores cover the whole estate the assistant will serve.
At the build gate, security for AI starts from an uncomfortable premise. The NCSC argues that a language model keeps no firm boundary between instructions and data, so prompt injection may never be fully mitigated, and OWASP's 2026 list says no reliable prevention exists [14][13]. The assistant reads contractor reports and resident emails, any of which could carry instructions, so the design limits what a manipulated model can do. Authorisation lives in application code, credentials never sit in the prompt, and the assistant drafts a work order that only the application can raise, after checking the user's own permissions [13]. Privacy asks that a development environment holding raw personal data be protected to a standard similar to any system that handles such data [16].
Before release, red teaming [2] should check whether the assistant will hand one resident's phone number to another user [13]. Accuracy is measured against the thresholds fixed at the idea gate, and the oversight is tested too. OWASP warns that a persuasive explanation can lead a person to approve a harmful action [17], so the approval screen should show the exact action being approved. Release then turns the records into a package: a hash of the model and its configuration, the test results, and a documented acceptance of the residual risk [18][3], which I would have signed by a named approver.
In operation, CSA asks owners to log inputs such as prompts, because third-party providers may not keep them, and to monitor outputs for anomalies and drift [3]. The joint guidance on deploying AI securely adds logs of outputs and errors [18]. CSA's agentic addendum adds trace IDs that link each input, output and tool call, so a decision path can be rebuilt from tamper-evident logs [15].
Here are the records each gate should leave behind.
| Gate | Security asks | Privacy asks | AI asks | Record left behind |
|---|---|---|---|---|
| Idea | What can it reach and change? | What is it for, and which personal data does that need? | How much harm could a wrong answer do, and what is good enough? | Inventory entry with a named owner, threat model, impact assessment, thresholds dated before testing |
| Data | Where did each source come from? | Retrieval store or model weights? | Does the data cover the cases it will meet? | Lineage record |
| Build | What stops a manipulated model? | Is raw personal data in the build environment protected? | Does every answer cite its records? | Versioned prompts and retrieval settings, a log of prompt changes |
| Test and release | Did red teaming pass? | Can one user's data reach another? | Were the thresholds met, and does the oversight work? | Test reports tied to the version; release record with hash, residual-risk acceptance and approver |
| Operate | Did every action stay within its permissions? | Who owns the prompt log, and when is it deleted? | Is performance drifting, and are overrides rising? | Trace-linked action log, drift and override reports |
| Retire | Were model and data disposed of securely? | Were retention limits met? | Is the decision record archived? | Disposal record: what was deleted, what was kept, for how long and why |
A shared gate earns its keep where the disciplines disagree, and the helpdesk has three such points.
The wheelchair is the first. Minimisation argues for stripping it out of the tickets, while fair prioritisation of lift repairs may depend on knowing it. The EU AI Act, as amended in July 2026, allows sensitive data for bias detection only where strictly necessary, with the reason written into the processing record [19]. The PDPC wants the reasons for using identifiable data in place of anonymised data documented and decided at an appropriately senior level [16].
Second is the log. The record that answers the security question is itself personal data, and the PDPC treats prompts, outputs and agent activity as data sources a deployer must track, assign to an owner and protect [11].
Retirement brings the third. CSA asks for secure disposal of data and models [3] and Cavoukian for secure destruction on time [4], but assurance still needs some records kept: for high-risk systems the EU Act sets a six-month floor for logs [10].
Privacy-enhancing technology has a price too. NIST says differential privacy in model training usually lowers accuracy, sometimes significantly [20], so Cavoukian's hope of full privacy with full function does not always hold for AI. The design gate is where an accountable owner makes each trade and writes down why.
Singapore's Model AI Governance Framework asked for this in 2020, suggesting an audit trail of model training and AI-assisted decisions, and a central process log that helps show the design was responsible and the outcomes justifiable [7]. Those records usually belong to the adopting organisation: CSA writes for system owners [3], and the PDPC makes the deployer primarily responsible for ensuring that a system it buys meets the PDPA [11]. For Singapore firms whose AI output is used in the EU, the Act's high-risk duties apply from 2 December 2027 for stand-alone systems [19][10].
A system built this way lets the three lines of defence work without reconstruction, much as I set out in the control framework. The first line builds the system and keeps its records. The second sets the thresholds and permission limits and attests to them. Internal audit re-performs, replaying a sample of decisions from the log and checking that the model in production is the one the release record approved.
In 2018 and 2019 I delivered audits and risk advisory at Protiviti for financial-services clients, work that starts after a system is built, with a request for evidence that someone then has to assemble. Two synthetic demos on this site show the difference. Work Order Miner reads a maintenance system that reports 93.8% SLA compliance and finds that its own event log supports 73.4%. Snap to Work Order writes its evidence as it runs. Its trail tags every step as system, AI or human, logs the model's confidence against a 0.75 threshold, and records the named approver and any override with its reason. A review of the second starts from the record.
A design review that can answer these has already done most of the audit.