Norwegian employers are being encouraged to put AI to work. On 2 October, the government and the main employer and employee organisations announced an agreement on responsible AI adoption in working life, linking productivity with employee participation and skills. For a company considering OpenAI, Anthropic, Codex or Claude Code, the practical question remains: what can we let these tools read, and what can we let them do?
There is no general GDPR ban on using these services. Nor does buying a business subscription make every use lawful. My view is that management should approve a defined workflow, its data and its authority—not give an unrestricted approval to a brand.
The Norwegian AI law is not the starting gun
In its 4 August update, the government said it aimed to submit the Norwegian AI law to Parliament in spring 2027, with a further consultation planned for autumn 2026. That is a legislative ambition, not a confirmed commencement date. The same announcement stresses that existing privacy and other laws already apply to AI. Companies should check the Norwegian implementation status before rollout; EU-facing activities may also require a separate assessment of the EU AI Act’s territorial scope.
This article focuses on ordinary internal business workflows. Healthcare, financial services, public administration and security-sensitive activities can have additional requirements. It is a practical management analysis, not a legal clearance for a particular deployment.
What I would allow in a first rollout
These are proposed company-policy boundaries, not statutory safe harbours. Each still needs a review of the actual data, contracts and system permissions.
- A sensible starting point: drafting from public information, searching approved internal guidance without employee case files, and generating tests with synthetic data. Check confidentiality and intellectual-property rights even when personal data is absent.
- Allow after a documented assessment: summarising customer tickets, retrieving restricted documents or using a coding agent in a private repository. Minimise personal data, preserve the requesting user’s access rights, and resolve provider terms and transfers first.
- Keep out of the initial rollout: unrestricted inbox access, bulk exports of customer records, personnel and health files, autonomous payments, destructive production changes, and automated hiring or credit decisions. Some may be lawful under specific conditions; they deserve their own approval process.
“Internal” describes the audience. It does not mean the processing stays inside the company. Map what leaves the device through model requests, connectors, search, telemetry, support submissions and logs.
GDPR: six questions before connecting real data
1. What is the purpose, and which lawful basis covers it?
Datatilsynet requires a lawful basis for each purpose. “We want to use AI” is not a sufficiently useful description of the work. “Prepare a draft answer to a customer’s delivery enquiry” gives the assessment a concrete starting point.
For a private company, legitimate interests may be relevant, but require a real interest, necessity and a balancing of individual rights. Consider less intrusive ways to achieve the same purpose. An existing customer relationship does not automatically justify every new analysis. Employee consent is usually unsuitable because of the power imbalance; do not make a consent checkbox the foundation of the rollout.
2. Can we use less data?
Apply purpose limitation, data minimisation and storage limitation. Remove identifiers and irrelevant attachments before sending a ticket to a model. Replacing a name with a customer number is usually pseudonymisation, not anonymisation. Health information and other special-category data require an Article 9 condition as well as an Article 6 basis. See GDPR Articles 5, 6 and 9 and Recital 26.
3. Who processes it, and under which agreement?
Where your company determines the purpose, it will ordinarily be the controller. Where a provider processes personal data on your behalf, Article 28 requires a data-processing agreement. Check instructions, subprocessors, deletion, security, assistance with rights requests and breach handling. Identify any separate provider purposes rather than assuming every activity is processing on your behalf. A signed agreement does not supply your lawful basis. These duties follow from GDPR Articles 4 and 28.
4. Does anything leave the EEA?
Datatilsynet says the US adequacy decision remains in force. It can support transfers to covered organisations on the Data Privacy Framework list. Verify the exact recipient and certification scope; a US address alone is neither permission nor prohibition.
Where adequacy does not cover the transfer, assess another valid mechanism, such as standard contractual clauses, including the destination’s laws and necessary supplementary measures. Map onward transfers and remote access too. An EU storage region does not establish that all inference, support and logging stay in the EEA. Keep a fallback if the transfer basis changes.
5. Do people understand the use, and can they exercise their rights?
Explain the processing, purposes and recipients through the relevant privacy information. Make access, correction and deletion work across stored conversations, retrieved copies and logs, subject to applicable exceptions. Set retention periods and test the deletion process. These are operational consequences of GDPR Articles 12–17 and 25.
6. Is a DPIA or another legal review required?
A data protection impact assessment is required where processing is likely to create a high risk to individuals; new technology is a factor, not an automatic exemption or an automatic trigger on its own. Document screening and consult the data protection officer where appointed. Unmitigated high risk requires prior consultation with the supervisory authority. Article 22 separately restricts solely automated decisions with legal or similarly significant effects, subject to exceptions and safeguards. A rubber-stamp reviewer is not meaningful human involvement. See Articles 22, 35 and 36.
OpenAI and Anthropic: inspect the purchased product
OpenAI’s API documentation says API data is not used for training by default unless the customer opts in. It separately describes abuse-monitoring retention, application state, and eligibility and feature limitations for zero data retention and regional controls. “Not used for training” does not mean “nothing is stored”. Do not assume API controls automatically cover a ChatGPT or Codex subscription.
Anthropic distinguishes commercial and consumer use of Claude Code. Under commercial terms, code and prompts are not used to train generative models unless the customer opts in. Consumer account settings differ. Local execution still sends data to the model service; local transcripts and feedback submissions also need attention.
I would ask procurement to record the exact plan, contracting entity, deployment route, model features, retention exceptions and subprocessor list. Then I would have IT verify the settings with a test account. A cloud reseller or an EU region changes the assessment only to the extent that the actual contract and data flow change.
How to run Codex, Claude Code and internal agents
A coding agent needs two separate approvals: permission to send repository material to the selected service, and permission to execute commands. A sandbox can constrain actions while the model still processes code remotely. Both Codex and Claude Code document permissions and sandbox controls; defaults and coverage vary by environment.
For an initial coding workflow, I would use a dedicated development environment, a scoped repository, synthetic test data and short-lived credentials. Exclude production secrets and customer database copies. Let the agent propose a branch and run tests. Require independent code review, security checks and protected deployment approval before changes reach production. Test that blocked reads, outbound requests and production writes actually fail.
For a custom internal agent, put a company-controlled service between the model and business systems. Authenticate the employee, retrieve only authorised records, minimise the model input and validate every requested action on the server. The model may request “update this ticket”; the service decides whether this user can update that ticket and which fields may change. Avoid giving the model a reusable administrator credential.
Emails, websites and repository files can contain hostile instructions—prompt injection. Treat them as untrusted input. An instruction in a document must not grant permission to export data or send money. Review connected tools, including MCP servers, as additional software and data recipients. Log decisions and actions with restricted access, cap spending and execution, and provide a tested stop and recovery procedure. These are my recommended design controls; the correct implementation depends on the workflow.
In Norway, involve employees before monitoring them
An assistant that helps write a report is different from a system that scores the writer. If agent logs or productivity analytics become employee control measures, Working Environment Act Chapter 9 requires an objective justification and proportionality, early discussion with employee representatives, information to affected employees and regular evaluation. Assess applicable participation and collective-agreement obligations as well. Do not quietly turn security logs into performance rankings.
The risk of doing nothing also belongs in the decision
My assessment is that a blanket freeze can leave manual errors, slow service and security backlogs untouched. It may also encourage staff to use personal tools outside approved processes. Those are risks to investigate, not proof that every AI investment pays off. Automation can add review work, new vulnerabilities, supplier dependence and costs of its own.
Run a bounded pilot against the existing process and a simpler automation alternative. Measure completed work, quality, review time, incidents and total cost. For example, if a hypothetical team saves 30 hours a month but spends 12 reviewing and correcting output, the gain is 18 hours before running costs. That is capacity; it becomes a business benefit only when the team uses it well.
I would give the first month a concrete sequence: choose one owner and task; complete the data and contract review; test in an isolated environment; then evaluate a limited live pilot only once the necessary safeguards are in place. Pause on unauthorised access, material errors or an inability to trace actions. Expand on evidence of net benefit.
The useful management decision is specific: this team may use this service for this task, with these records and these permissions, under this owner’s responsibility. For examples of evaluating benefits and failures, read AI in medium-sized businesses: what works, what goes wrong.
Sources and scope
Sources reviewed on 11 October 2026; linked at the relevant claims. Government announcements describe policy and legislative intentions. GDPR and regulator guidance support the legal discussion; supplier documentation describes product behaviour, not a Norwegian compliance certification. The rollout boundaries and business-risk assessment are my analysis. Recheck legal status and the purchased service before implementation.