NIS2 + AI tools: what a Czech team must have in place so as not to violate internal rules

AI tools are spreading through Czech companies faster than internal rules. The typical scenario looks simple: sales summarizes a meeting in ChatGPT, development rewrites a piece of code via GitHub Copilot, HR has a job ad edited, and management expects higher productivity. But from the perspective of security and compliance with internal policies, the problem lies elsewhere: who is allowed to use which tool, what data may be entered into it, where logs are stored, who approves new integrations, and how the company can demonstrate that it had real control over AI usage.

NIS2 itself does not say that a company must ban generative AI. However, it pushes risk management, access management, asset inventory, incident handling, continuity, and management accountability. As soon as employees use external AI services when working with company data, a new layer of third parties, new data flows, and new failure states emerges. The minimum setup therefore should not be a theoretical policy sitting in a drawer, but a set of operational rules that can be checked and enforced.

This article summarizes the practical minimum for Czech companies that want to use AI without improvisation: what to set up in processes, access, and logging, what to delegate to IT and compliance, what management should approve, and when it is better not to allow AI into a specific step at all. If you are only now mapping which tools are actually being used in companies, the overview of AI tools on AIVýběr is also useful. For comparing specific office assistants, the directory of articles about ChatGPT is also helpful, because chat tools are often the most common source of uncontrolled data sharing in practice.

1. First, determine which AI tools are allowed in the company and under what mode

The first mistake is usually organizational: the company deals with prompt training, but does not have a list of approved tools and their permitted modes. The minimum is not “you may use AI reasonably,” but a short catalog of services that states four things for each service: what it may be used for, what data must not go into it, who may activate it, and who owns the risk.

OpenAI

In practice, it is worth dividing tools into at least three classes:

Allowed for routine work – for example, Microsoft Copilot for Microsoft 365 in the company tenant, if deployed with corporate identity and access management.
Allowed under conditions – for example, ChatGPT Team or Enterprise only for specific departments and only without entering special categories of personal data, trade secrets, or non-public contracts.
Prohibited – public AI chatbots used without a corporate account, anonymous browser extensions, text and image generators without a contractual relationship, or without the ability to trace data processing.

What to do specifically: create a one-page “AI service register.” For each service, list the name, provider, data type, processing location according to official documentation, available admin functions, logging, sign-in method, and owner within the company. Without an entry in the register, the tool must not be used for company data.

Who it is for: CIO, CISO, DPO, heads of IT, and process owners in HR, sales, customer support, and development.

When not to use this: if someone is pushing for a blanket ban on all AI services without distinction. That may look safe, but in practice it leads to shadow use of personal accounts and loss of control.

Verifiable details for common services: OpenAI offers Team and Enterprise plans for businesses, Microsoft offers Copilot for Microsoft 365, and GitHub offers paid versions of Copilot for businesses. Features such as SSO, user management, audit logs, or plugin restrictions vary by plan. Indicative pricing: ChatGPT Team from USD 25 per user per month with annual billing, ChatGPT Enterprise individually priced, Microsoft Copilot for Microsoft 365 USD 30 per user per month, GitHub Copilot Business USD 19 per user per month, GitHub Copilot Enterprise USD 39 per user per month. Prices may change and must be verified in official price lists.

What the minimum decision rule should look like

Every employee should be able to decide within half a minute whether they may use AI. A practical rule can sound like this: “If the task contains non-public data about a customer, employee, contract, pricing, source code, or security architecture, use only a tool from the approved register and only in a corporate account.” This is far more effective than general calls for caution.

2. Set data boundaries: what must never be entered into AI and what only after approval

The most important operational rule is not model choice, but data classification. Most problems arise when content is copied into a prompt: contracts, offers, bug reports with customer names, payroll documents, internal security procedures, or non-public roadmaps. If the company does not define clear boundaries, employees will assume that “if it is just a summary,” it is fine. It is not.

The practical minimum is to divide data at least as follows:

Forbidden to enter – special categories of personal data, birth numbers, health data, non-public contracts without anonymization, secret credentials, non-public security configurations, private keys, production database dumps, source code of critical systems without approval.
May be entered after modification – texts after anonymization, business documents after removing identifiers, internal notes without names and amounts, code samples without secret keys and without links to critical architecture.
Generally allowed – publicly published texts, marketing drafts without internal data, general wording, templates, public documentation.

What to do specifically: introduce mandatory data preprocessing before entering anything into AI. In practice, this means anonymizing names, emails, phone numbers, contract numbers, customer company IDs, and all unique identifiers. For technical teams, also remove tokens, keys, internal URLs, server names, and IP addresses.

Who it is for: all departments working with personal data, business information, or non-public technical documentation.

When not to use this: if the value of the task lies directly in the exact context and anonymization would destroy the purpose of the work. Typically, legal review of a specific contract, analysis of a security incident, or troubleshooting a production outage with real identifiers. In such cases, an internal process without an external AI tool is more appropriate.

The point of this step is simple: even if the provider states that it does not use data from enterprise plans to train models, you still have to deal with data transfer to a third party, internal authorization, possible retention policies, and your own responsibility for who sent the data and why.

Do not confuse “not used for training” with “I can send anything”

A provider may declare that content from enterprise accounts is not normally used for model training, but that does not solve everything. You still need to check contractual terms, personal data processing, subprocessors, retention period, logging options, regional availability, and whether the company can demonstrate the purpose of use. From the perspective of internal policy, this is the difference between “lower risk” and “no restrictions.”

3. Access and identities: no personal accounts, mandatory SSO, and roles by job

As soon as employees use AI through personal accounts, the company loses the ability to properly terminate access, audit usage, and enforce settings. The minimum standard is therefore clear: no corporate use through private identities if an approved enterprise version of the service exists.

What to do specifically:

Enable SSO via Microsoft Entra ID, Google Workspace, or another corporate identity provider wherever the service supports it.
Enforce MFA for all administrators and for all users of services that work with internal data.
Ban shared accounts. Every user must have their own identity.
Set roles: regular user, integration approver, administrator, security oversight.
Connect AI services to the standard joiner-mover-leaver process, meaning onboarding, role change, and employee departure.

Who it is for: IT administrators, the security team, and HR responsible for the account lifecycle.

When not to use this: if you are testing a public tool one-off in a sandbox without company data. Even there, however, it must be clearly stated that this is an experiment without production use.

The practical impact is significant. When an employee leaves, it is not enough to deactivate email. You must also terminate their access to AI tools, remove any API keys, exports, plugins, and shared workspaces. With GitHub Copilot, it is also advisable to check who has access to organizations and repositories. With Microsoft 365 Copilot, you deal with permissions over SharePoint, OneDrive, Teams, and Exchange, because the model draws from what the user is legally allowed to access. Poorly configured permissions in M365 can therefore also show up in AI outputs.

The most common weakness: access rights in M365 are not ready for Copilot

Copilot for Microsoft 365 does not bypass permissions, but that is exactly why it can expose long-term disorder in access settings. If too many people have access to historical folders, meeting notes, or payroll documents, AI only speeds up finding content that was already there. Before deploying Copilot, it is therefore necessary to review rights in SharePoint, Teams, and OneDrive, otherwise the company will only make the problem more visible on a larger scale.

4. Logging and audit: without records, you cannot prove usage is under control

Many companies address AI policies but keep almost no operational records. Then, during an internal audit or incident, they cannot answer basic questions: who used the tool, when, from which account, with which integration, what permissions they had, and whether the relevant security rules were active. You do not have to log the full text of every prompt, but you must have an audit trail for traceability and incident response.

What to do specifically: define a minimum set of logged events:

logins, failed logins, and MFA changes,
creation, modification, and deletion of user accounts,
role changes, addition of an administrator,
activation or deactivation of connectors, plugins, and API access,
creation and rotation of API keys,
data export, sharing of a workspace or project,
changes to retention policy and security settings,
if available, metadata about model and application usage.

Who it is for: the security team, SOC, internal audit, and identity administrators.

When not to use this: do not broadly store prompt and output content where doing so would create new unnecessary risk for personal data, trade secrets, or employment disputes. Log primarily metadata and administrative actions, and content only where you have a clear purpose and support in internal rules.

Larger enterprise services typically offer audit logs, admin consoles, and export to SIEM. However, the specific scope must be verified in the documentation and plan. For example, Microsoft typically builds on the audit capabilities of Microsoft 365 Purview and Entra ID, GitHub has an audit log for organizations and enterprise accounts, and enterprise AI services often offer an admin console, workspace management, and billing overviews. The level of detail varies by plan.

How long to keep logs

There is no single universal retention period. In practice, however, it is worth aligning retention with the internal policy for security logs and with the period during which you actually handle incidents and internal investigations. The important thing is to have the rule written in advance: where the logs are, who has access to them, how they are protected, how long they are kept, and when they are deleted.

5. Approval of new integrations and APIs: the riskiest part is often outside the main chat window

Companies often deal with whether employees may use ChatGPT or Copilot, but overlook extensions, plugins, connectors, and automations. Yet this is exactly where the greatest operational risk arises: the AI service connects to CRM, helpdesk, cloud storage, or a Git repository and starts working with a broader set of data than the user realizes.

What to do specifically: introduce a mandatory lightweight approval process for every new integration. It should not be ten pages long, but it must answer these questions:

What data does the integration read and write?
Is the access read-only, or can it modify data?
Who owns the integration?
How is access removed when an employee leaves?
Are logs and audit of administrative changes available?
Is it possible to limit the scope of access only to a specific team or space?

Who it is for: SaaS administrators, enterprise architects, the security team, and owners of business applications.

When not to use this: if the integration requires blanket write access to a critical system without fine-grained permission management, or if it is unclear where the vendor’s responsibility ends and the company’s responsibility begins.

This is exactly where the principle “read-only first, write later” pays off. If an AI connector can initially only read documentation, a knowledge base, or a selected project, you get a useful pilot without the risk of uncontrolled changes. Allow writing to CRM, ticketing, or internal wikis only after evaluating output quality, accountability, and logging.

6. Incident processes: an AI error is not just a bad answer, but also a security event

Companies still underestimate that an AI-related incident does not have to look dramatic. It may be an employee mistake, such as entering a non-public document into an unapproved tool. Or an integration that obtained broader permissions than necessary. Or a faulty output based on which the team made a system change. Without a clear procedure, these situations are handled ad hoc, which is exactly what NIS2 is meant to prevent.

What to do specifically: add AI scenarios to the internal incident response plan. At minimum these:

sensitive data entered into an unapproved AI service,
leak of an API key associated with an AI application,
unauthorized activation of a connector or plugin,
harmful or incorrect AI recommendation that led to an operational change,
suspicion of a former employee accessing a corporate AI service.

For each scenario, write down responsibility, the first 60 minutes, escalation contacts, the method of evidence preservation, and the decision on when to inform management, legal, the DPO, and possibly the customer.

Who it is for: SOC, IT operations, legal, DPO, and line managers who approve tool usage.

When not to use this: do not mechanically adopt a general incident playbook without adding specific AI services, admin paths, and vendor contacts. Without these details, the plan is slow during a real event.

A practical rule for the first response

If someone enters sensitive content into an unapproved service, the first step is not to look for the culprit, but to stop further spread: disconnect the integration, change keys, revoke sharing, document the time, user, and scope of data, and assess whether it involved personal data, trade secrets, or technical documentation with a security impact.

7. Training must be short, mandatory, and tied to specific work

A one-off webinar on “how to write better prompts” is almost worthless from the perspective of internal rules. What an employee mainly needs is to distinguish when to use AI, when not to use it, how to modify input data, and where to report a problem. This can be taught in 20 to 30 minutes if the training is based on the real work of the given team.

What to do specifically: prepare three versions of micro-training:

Office teams – text summaries, notes, translations, emails; emphasis on anonymization and work with non-public documents.
Development and IT – work with source code, logs, configurations, secret keys, and automations.
HR and legal – job ads, internal communication, personal data, contract texts, prohibition on entering specific materials without approval.

End each training with a short test containing four to six real-life situations. Anyone who does not pass should not have access to the corporate AI service until they do.

Who it is for: all users of approved AI tools, including management.

When not to use this: when the company does not even have a basic policy and list of approved tools. Training without operational rules means forcing people to improvise.

Good training has one more feature: it does not just say “do not make mistakes,” but gives permitted alternatives. For example: “Need to summarize a contract? Use an internally approved tool and first remove names, amounts, and identifiers.” Without an alternative, employees usually reach for the fastest public service.

8. Practical scenarios: what to do in common company situations

Scenario 1: A salesperson wants to summarize notes from a customer meeting

Correct procedure: use an approved corporate tool, and before entering anything remove the customer’s name, emails, prices, order numbers, and non-public commitments. Use the output as a draft, not as the final record without review.

Who it is for: sales, account management, customer success.

When not to use this: if the notes contain non-public pricing terms, disputed contract points, or sensitive data of natural persons and no approved enterprise tool is available.

Scenario 2: A developer wants to use AI for code refactoring

Correct procedure: use a company-managed GitHub Copilot or another approved tool, do not enter secret keys, production configurations, or parts of the system with security-critical logic without explicit permission. Every suggestion goes through code review and security review like a normal contribution.

Who it is for: development, DevOps, QA.

When not to use this: for code related to authentication, cryptography, permission management, security logic, and incident tooling, if the team does not have a clear review process and accountability for the result.

Scenario 3: HR wants to edit a job ad and an email to a candidate

Correct procedure: use AI only for stylistic editing of a template without the candidate’s personal data. The input should be anonymous text, not the full CV, candidate evaluation, or internal interview notes.

Who it is for: HR, recruitment, internal communication.

When not to use this: when deciding about a candidate, sorting sensitive data, or working with specific HR materials without internal approval and legal assessment.

Scenario 4: Support wants AI for suggested replies from the helpdesk

Correct procedure: start with read-only mode over a selected knowledge base, without access to full customer tickets. Only after verifying quality and logging should usage be expanded to internal reply drafts.

Who it is for: customer support and service desk.

When not to use this: if the ticket contains personal data, payment data, credentials, or technical details from an incident and anonymization or an approved integration is missing.

9. Limits: what the minimum setup does not solve and where companies draw the wrong conclusion

Minimum processes, access, and logging are not the same as secure deployment without further questions. They address basic control, not output quality, legal interpretation of every use, or technical weaknesses of specific models. Companies therefore often make one of three mistakes.

Mistake 1: “We have an enterprise plan, so we are safe.” No. The plan may reduce some risks, but it does not solve your access settings, internal permissions, data classification, or employee misuse.
Mistake 2: “We will log everything.” No. Excessive content logging can create new legal and security problems. You need proportionate and purpose-driven logging.
Mistake 3: “AI is just another SaaS application.” Only partly. With generative AI, you also deal with prompts, context, possible hallucinations, automated suggestions, and people’s tendency to overestimate the quality of answers.

What to do specifically: supplement minimum governance with a human review rule. Every output that affects a customer, contract, security change, personnel decision, or the company’s public statement must be verified before use by a person responsible for the given process.

Who it is for: management, team leads, and process owners.

When not to use this: do not try to cover highly regulated or high-risk use cases with this minimum set of rules without deeper legal, security, and architectural assessment.

FAQ

Does the use of ChatGPT or Copilot automatically fall under NIS2?

Not automatically. NIS2 primarily addresses cyber risk management for affected organizations. However, if a company falls under NIS2 and employees use AI when working with company data or systems, it becomes a relevant part of risk management, access, third parties, and incidents.

Is it enough to issue an internal policy and the problem is solved?

No. A policy without technical enforcement and without logging has little value. You need approved tools, corporate identities, roles, an inventory of integrations, training, and a basic audit trail.

Can we allow employees to use public AI chatbots for work?

Yes, but only very limitedly and only for public or anonymized content. As soon as non-public company data, personal data, contracts, code, or technical documentation are involved, only an approved enterprise mode or a ban makes sense.

Do we have to log prompt content?

Usually not across the board. More important are metadata, administrative changes, identities, integrations, exports, and access events. Log prompt content only where you have a clear purpose, support in internal rules, and can handle the legal and security impacts.

Is ChatGPT, Microsoft Copilot, Gemini, or another tool better?

For governance purposes, that is not the main question. More important is whether the service supports corporate identities, user management, audit, a contractual regime for enterprises, integration control, and clearly described data processing. Only then should you address model quality and price.

How to get started if the company currently has nothing?

Start in three weeks with three steps: write down approved and prohibited tools, introduce a ban on personal accounts for corporate work, and launch short training with a rule on what data must not be entered into AI. Only then expand integrations and automations.

Conclusion

The minimum setup for AI in a company is not complicated if you follow the right order. First determine which services are allowed and under what mode. Then clearly define what data must not go into AI and what must be anonymized. Next introduce corporate identities, SSO, MFA, and roles by job. Without that, it makes no sense to talk about accountability. Only then deal with logging, integration approvals, and incident playbooks.

Companies that skip this minimum usually do not gain higher efficiency, but only less visible chaos. And from the perspective of NIS2, that is the worst combination: tools are being used, data is flowing out, decisions are not traceable, and management formally assumes that everything is under control. If AI is to be a real operational tool in the company and not improvisation on the edge of internal rules, it must have a clear owner, limited inputs, corporate access, and an audit trail. That is the reasonable minimum from which safe growth is possible.

Official sources for verifying details: OpenAI Business, OpenAI Enterprise Privacy, Microsoft Copilot for Microsoft 365, Microsoft Learn, GitHub Copilot Business, GitHub Copilot Enterprise.

Recommended AI stack for implementation

Choose tools according to your budget and level of automation. Below is a direct overview of services for implementing the project.

Service	Service description	Offer
NordVPN	VPN service for privacy protection and secure connections.	Open offer
Semrush	SEO and marketing platform for analysis and traffic growth.	Open offer
Make	Advanced visual automation for workflows and integrations.	Open offer
Hostinger	Web hosting and domains for fast website launch.	Open offer
Fiverr	Marketplace for freelancers and external specialists.	Open offer
Adobe	Creative tools for graphics, video, and digital content.	Open offer
Canva	Online design tool for graphics, presentations, and social media.	Open offer
Jasper	AI tool for marketing copy and content campaigns.	Open offer