Security, Audit and On-Premise Requirements for Government AI Copilots

When agencies evaluate an AI copilot, the feature demo is rarely the final hurdle — the security review is. Does data leave the country? Who can see what? Is every AI output logged and reviewable? Can the whole system live in the agency's own server room? This article organizes the six security requirements, audit design and on-premise deployment options for government AI copilot adoption, with a checklist ready for procurement specs.

Start with the framework: a regulatory map for government AI security

Agencies deploying an AI copilot are not dealing with a single regulation, but with four overlapping layers: the security responsibility tiers and system protection baselines established by the Cyber Security Management Act, the boundaries the Personal Data Protection Act sets on the collection and use of personal data, the reference guidelines the Executive Yuan has issued for generative AI use by public agencies, and the requirements government procurement and Joint Supply Contracts place on supply chain security and vendor qualifications. Almost every one of the six requirements covered later in this article maps back to one of these four layers: the clauses that make it into a procurement specification are, more often than not, not quality commitments the vendor invented, but things the regulations already require.

The following is a general framework overview to help staff build a mental model. Actual applicability, procedural requirements, and required actions should still follow the competent authority's latest announcements, your agency's assigned security responsibility tier, and the determinations of your agency's security and ethics personnel.

The common spirit running through these four layers of regulation really comes down to two things: controllability and auditability. Controllable means the agency can always state where the data is, who is processing it, and who can see it. Auditable means that when someone asks after the fact, the agency can produce records to back it up. Once this is understood, the six requirements that follow stop looking like a vendor's feature checklist and start looking like concrete ways of building controllability and auditability into the system design.

1. Data Sovereignty: Data Staying Onshore Is the Baseline

Most public-cloud generative AI services run inference in offshore data centers — a fundamental obstacle for government business, since once official information enters an offshore service, the agency loses control over where the data flows. A compliant AI copilot system should ensure that data hosting and model inference both stay within Taiwan, the vendor holds ISO 27001 certification, and data transport uses TLS 1.2 or above. Procurement specs should state explicitly that data storage and processing must not leave Taiwan.

A specification clause could read: All storage, processing, and model inference of data under this project shall be completed within Taiwan, and shall not be transmitted in any form to offshore data centers or offshore AI services. The vendor shall include, in the bid documents, a statement of data center location and ISO 27001 certification. If third-party components or outsourced processing are involved, the processor, processing location, and data items must be listed item by item, and any change must be reported to the agency for approval in advance. Writing this into the specification filters out non-compliant proposals at the bidding stage, avoiding the discovery during review that the architecture cannot be adjusted.

2. Deployment Options: Cloud, Private Cloud and On-Premise

By business sensitivity, deployment options range from Taiwan-based cloud (suitable for monitoring built mainly on public sentiment), through government private cloud, to full on-premise — where system and models run in the agency's own server room and even model inference needs no external connection. For an AI copilot integrating internal documents and sensitive data, target on-premise directly; the external sentiment collection layer can stay in the cloud, forming a "cloud outside, on-premise inside" hybrid that balances data coverage with the security boundary.

The reason for recommending the hybrid external-cloud/internal-on-premise architecture is simple: external sentiment data is high in volume and its sources change frequently, so cloud-based collection and cleaning is the most efficient approach, and this data is public to begin with. Internal official documents and assessments, on the other hand, have no need to ever leave the agency. Separating the two with a clear boundary means the agency only needs to explain one thing externally: what data crosses the boundary, and in which direction it flows. That is easier to explain clearly during review than moving everything to the cloud or cramming everything on-premise.

How to choose an on-premise model: open-source options available to Taiwan agencies

Once you've decided to go on-premise, the next question is where the model comes from. There are currently four main categories of open-source or open-weight models that Taiwan agencies can realistically consider: TAIDE, Gemma 4 31B, GPT-OSS, and the Mistral family. The selection criteria are not leaderboard scores but three things: whether the license permits internal agency use and customization, how well the model handles Traditional Chinese and official-document phrasing, and whether it runs on a single GPU or a small number of high-end GPUs. For most agencies' first on-premise system, data center space and budget are the constraint, so hardware feasibility often becomes the deciding factor before model capability does.

One red line needs to be stated up front: models developed in China (such as Qwen and DeepSeek) are not recommended for Taiwan government agencies and regulated enterprises even when deployed on-premise with no external connectivity. There are three reasons: concerns over data sovereignty and the model's country of origin, restrictions in government procurement on product origin and supply chain security, and the fact that subsequent maintenance and weight-update channels also originate offshore. In practice, this type of solution usually cannot pass an agency's security review — rather than being sent back late in the evaluation, it's better to exclude it at the first round of model selection.

As for the capability gap, on-premise open-source models are indeed still behind the most cutting-edge cloud models such as GPT-5.6, Claude Fable 5, and Gemini 3. But in government use cases, this gap can be closed architecturally: build the agency's regulations, past official documents, and meeting minutes into a knowledge base, and use a RAG architecture so the model bases every answer on retrieved source text. Answer quality then depends on how well the knowledge base is curated, not on how much the model itself remembers. In other words, the effort should go into data governance, not chasing model leaderboards.Taiwan Enterprise LLM Selection Guide has a more complete comparison of license terms and hardware requirements across models, and can serve as reference material for selection meetings.

3. Access Control: Who Can See What, Who Can Ask What

The information an AI copilot aggregates varies in sensitivity: public sentiment is open to all, interpellation debate materials are restricted to the staff circle, and internal assessments touching individual cases are accessible only at specific levels. The system should support role-based access control (RBAC) — data visibility and feature permissions set by rank and business role — combined with multi-factor authentication (MFA). Within the same system, the executive, department heads and case officers should see different content and be able to run different queries.

It's best to draft the permission matrix as early as the requirements interview stage and attach it to the specification. Using a typical agency org structure as an example, visibility scope generally looks like this:

• Executive: agency-wide topic overview, cross-department risk roll-up, all alerts and assessment reports
• Department head: topics related to their department's business, and assigned tasks and progress for their staff
• Advisory staff: interpellation Q&A materials, response drafts, cross-department topic context, but excluding sensitive case-specific content
• Case officer: raw data and analysis results for topics they personally handle; can query but cannot export agency-wide reports

4. Usage Logging: Model Behavior Must Leave a Trail

Generative AI introduces a new audit subject: the model's own behavior. A compliant system should retain who queried what and when, which materials the model cited to produce each response, and who received alerts and briefings. These records serve two purposes — post-incident investigation of security events, and answering oversight questions about whether the AI is being misused. An AI system without usage logs is an audit blind spot in a government environment.

The specification can list the fields to be retained one by one, to prevent a vendor from waving it off with a single line like "the system already has logs." At minimum, it should cover:

• Requester: account, affiliated unit, and role/permission at the time
• Query time: start/end timestamps and source network segment
• Query content: the question the user entered or the monitoring conditions they set
• Model citation data: the documents, passages, or sentiment source list retrieved for this response
• Delivery recipients: recipients of alerts and briefings, delivery channel, and delivery time

These records should have a defined retention period and access controls: anyone who can retrieve the records must also leave a trace themselves, otherwise the audit trail becomes a new leakage channel in its own right.

5. Output Audit: What AI Wrote and What Humans Changed Must Be Separable

If press releases or response materials are AI-assisted, the agency must be able to answer: which parts did the AI write, who edited them, who approved them? The system should keep a complete version trail: the AI-generated version, human-edited version, editor, approver, cited materials and generation time. This is not only an audit requirement but a design that protects staff — when disputes arise, it proves that human gatekeeping actually happened.

A complete version trail should include at least the following fields, and should be exportable per document:

• The AI's initial output version and generation time
• Each human edit's version, the editor, and the edit time
• A diff between versions, showing which passages were rewritten
• The approver, approval time, and the approved final version
• The list of data sources cited in this output

6. Source Traceability: Every Conclusion Needs a Citation

Security review asks how data comes in and how it is protected; accountability asks how conclusions are produced. Every assessment and recommendation from an AI copilot should link back to original materials — news articles, social posts, official documents or meeting minutes — with the interface separating confirmed facts, sentiment observations and AI inference. Traceability should be a mandatory procurement condition: output that cannot account for its sources has no formal standing in government processes.

During acceptance testing, spot checks can verify whether this requirement is actually implemented: have agency staff pick any conclusion point at random from a report the system produced, then require the system to trace it back to the source data on the spot, confirming the source exists, the content matches, and the timing is correct. If what's pointed to is AI inference, the system should also clearly label it as inference rather than fact. Spot-check questions should be devised by the agency on the spot, with the pass criteria written into the acceptance items — this reflects real usability far better than reviewing a feature description in advance.

How to pass the security review: a four-step preparation process

Security reviews usually drag on not because the system fails to qualify, but because the preparation order is wrong: finishing the system first and only then going back to fill in documentation, only to find the architecture can no longer be adjusted to fit. It helps to treat the review as a four-stage process: self-assessment and tiering, document preparation, review and follow-up, and ongoing post-launch auditing. The first two steps should start before the contract is signed, and the fourth step needs to be written into the maintenance clause of the contract — otherwise the system runs out of control the moment it goes live.

1. Self-assessment and tiering: first confirm which bar you actually need to clear

The first step isn't finding a vendor — it's having the agency's security personnel confirm two things: the system protection tier this system falls under, and the sensitivity classification of the data that will enter the system. Two systems that are both called an "AI copilot" can face very different requirements depending on whether they only handle public sentiment monitoring or also integrate internal personnel and case data. List out, category by category, the data planned for import (public news, social posts, internal official documents, meeting minutes, case data), and note each category's sensitivity level and whether it contains personal data. This table directly determines whether the deployment mode should be the hybrid external-cloud/internal-on-premise model or fully on-premise, and also determines how deep the subsequent documentation needs to go. Skipping this step effectively lets the vendor decide the agency's risk appetite for it.

2. Document preparation: explaining the architecture clearly matters more than writing it beautifully

The core document is a system architecture diagram that marks the flow of data: where each piece of data comes from, which components it passes through, which host it's stored on, and who can access it — arrow directions and storage locations should all be clearly labeled. Other commonly required documents include the vendor's ISO 27001 certificate, a personal-data inventory and compliance statement, the permission matrix, a backup and business continuity plan, and a vulnerability scan or penetration test report. Vendors with prior government deployment experience usually have applicable document templates ready, and the agency only needs to adjust them for case-specific differences, which can save a substantial amount of back-and-forth.

3. Review and follow-up: consolidate issues into a to-do list

Review comments tend to cluster around a few fixed areas: whether data could leak, whether permission segmentation is actually enforced, whether records can be retrieved, and how vendor personnel's operational access is controlled. After receiving comments, it helps for the agency's case officer to consolidate them into a single to-do list, noting for each item whether the agency or the vendor is responsible, the expected completion date, and supporting documentation — rather than letting comments scatter across separate emails. Resolving all the questions and completing all the follow-up items in one round is usually much faster than trickling out fixes over multiple rounds.

4. After launch: annual audits and record-retrieval drills

Passing the review is only the starting point. Once the system launches, it should be included in the agency's annual security audit scope, with regular checks on whether permissions are updated as staffing changes, whether accounts for departed or transferred staff are actually deactivated, and whether backups can be restored. It's also worth scheduling a record-retrieval drill once a year: assume someone questions a piece of AI-assisted output — can the agency retrieve the complete query log and version trail within a reasonable time? Only after running the drill once do you know whether the records are genuinely usable, or merely exist. These requirements should be written into the maintenance contract, specifying the vendor's cooperation obligations.

Procurement Spec Checklist

• Data storage and model inference both within Taiwan; vendor holds ISO 27001 certification
• Full on-premise deployment option, or a hybrid of cloud external collection + on-premise internal knowledge
• RBAC role permissions and MFA, with permission changes logged
• Complete query and model usage logs retained, available for security audits
• AI output keeps a version trail: generated version, edited version, editor, approver, timestamp
• Every conclusion links to original sources; the interface separates facts, observations and AI inference
• Personal data handling complies with the Personal Data Protection Act: only public content collected, presented in aggregate