AI is meant to produce something, so it needs access: why the AIEE programme is built around its own server

The appeal of AI tools begins where watching turns into working: something is meant to come out of it that still runs the next day. At exactly that point the technology asks for something every company regulates carefully, namely access and rights. How to grant that access without turning your own IT into a test field: that is the question the AIEE server answers as the core of the programme.

An AI that is meant to produce something needs tools and rights

An AI programming environment is a different thing from a chat window. A chat window produces text that you then take further yourself. A programming environment produces a result that keeps running on its own: an evaluation, a workflow, a small program. Environments of this kind, Claude Code for example, are installed on a computer and pull in further tools. They are also granted rights. That means permission to read, write and delete files and to start programs. Those rights are needed to get the work done.

A new colleague is asked to draft a quotation. For that she needs the key to the filing cabinet, access to the price list and permission to save on the shared drive. Watch her read and allow nothing else, and no quotation arrives. Hand her every key instead, and on day 1 she also holds the personnel files and the customer records. Both outcomes are unsatisfying, and in both cases the environment is at fault.

Why the work machine is the uneasy place for first experiments

On your own work machine everything sits side by side: saved logins, customer documents, years of files, the quotation next to the private photo. 3 things tend to go wrong there, all 3 without any bad intent:

• a password ends up in a file that is then passed on;
• a folder gets tidied away that was still needed;
• data gets read that has nothing to do with the task, simply because it happened to be nearby.

There is also a more fundamental point, and it weighs more than any single incident: personal IT gets mixed with a test environment. At the beginning in particular, the limits of the tool are still unknown, because they have yet to be experienced. Experiencing them calls for a place where the experience stays without consequence.

Separation helps, and the 4 common routes to it separate to different degrees

The answer to this problem has been the same for decades and comes from the workshop: you practise on a test piece, not on the customer order. The reason is the same in IT as at the machine: a mistake costs little where nothing real is lying next to it. That is why every company running its own software keeps a test system alongside the live one. The same applies to first steps with an AI environment. Only here it rarely occurs to anyone, because the tool looks like a chat window when you open it.

In technical terms separation means 2 working areas that cannot see one another. What happens in one of them reaches the other neither for reading nor for writing. There are 4 common routes to this, and the real point is how sharply each one separates. Separated is more than a property a computer simply has or lacks. It is a question of which bridges between the two sides are left open.

1. A virtual machine or a container on your own computer. A virtual machine is a complete second computer running as a program inside the first. It has its own hard disk, its own users and its own operating system. The operating system is the base program that makes a computer usable in the first place. A container is the leaner version of that, a sealed-off working area for a single tool. Anthropic, the maker of Claude Code, recommends precisely these two routes in its security documentation. The AIEE server takes this route all the way: one server per participant, ready-made, run as a separate instance and tested in the way it is secured.
2. WSL. The abbreviation stands for Windows Subsystem for Linux, a function that ships with Windows. It lets Linux run inside the running Windows. Linux is a free operating system that a large share of the world's servers run on; in everyday office life few people ever meet it. This route is the most convenient one and at the same time the weakest. As delivered, Linux sees the Windows hard disk under the name /mnt/c and is allowed to write there. Windows in turn sees the Linux files. Windows programs can also be started from inside Linux, and they then run with the rights of the logged-in Windows user. Microsoft describes this in its own documentation as intended convenience and nowhere presents WSL as a security boundary. The 3 mishaps listed above can therefore still hit the real company data. Anyone using WSL as a test space closes those bridges first.
3. A second operating system on the same computer. At switch-on you choose which one starts. Separation is sharper this way than with WSL, because only one of them ever runs. Complete it is not, however. Both sit on the same disk, and as long as that disk is unencrypted, one system can read and change the other's files. There is a further point: the setup itself alters how the working disk is divided up, which makes it the most delicate step of these 4 routes.
4. A second computer. Here separation is complete, because it is physical. It is at the same time the route that costs money and desk space.

All 4 routes ask for the same trio, only in different doses: set it up, know your way around Linux to some degree, find the time. Setting up costs least with WSL, where a single command does it. In exchange, the most work remains afterwards until things are genuinely separated. With the virtual machine and the second operating system the effort sits in the build, with the second computer in purchase and upkeep. That trio rarely applies to a managing director, a shop-floor supervisor or a commercial lead. The time is missing anyway. So the entry fails at the setup, long before the first question about content is asked. That part, however, can simply be bought in. It is the cheapest place to spend money.

The AIEE server is the training workshop for the programme

This is where the server comes in. The training workshop of a machine builder holds real machines, real material and real tools. What it lacks is the live customer order. That is precisely why every move there is allowed to go wrong once, and precisely why more is learned there than by watching in production.

The AIEE server is that training workshop: a prepared, secured working environment that stands ready in the browser once you log in. Each participant gets a server of their own, run as a separate instance. Setup falls away, the tools are in place, the rights are set. Connections to the participant's own systems are absent by design, and each participant's environment stands on its own.

You may experiment with whatever you like. Full rights on your own server are part of the programme, and anyone who needs them gets them. There are undertakings in which a participant builds an agent server of their own from the first hour. Full rights are exactly what that takes. At the start they are held back. That is a safeguard for the first steps rather than a limit of the offer: someone who does not yet know what a command does should leave the base settings alone at first. The only limit that remains is the legal one. It is set out in the terms of participation. The limits that matter in the programme are different ones anyway. They are the limits of the tool: what an AI makes of an instruction, where it goes wrong, and how you spot it. Having met those limits yourself is the difference between a training session and an experience.

The benefit lands on 2 sides. The participant works on content from the first hour instead of on the installation. And the company's IT department stays out of it without missing anything. There is nothing to install, the devices stay as they are, and no rights are needed in the company network. Whoever uses the server signs in through the browser, just as with any other service on the internet. In larger organisations that is precisely the difference that counts: an installation such as WSL requires hardware and software approval, and most employees do not hold the rights to carry it out.

The comparison with building-block tools, fairly counted

The obvious objection runs: there are building-block tools, often called low-code. In them workflows are clicked together instead of programmed. Why a programming environment then? The objection is fair.

Tools of this kind are mandated in many companies. Anyone required to use them uses them, and that is fine. For many standard tasks they deliver a result quickly. 3 properties belong on the invoice as well:

• It remains a pre-built frame. The blocks come from the vendor, and whatever the vendor has left out is simply unavailable.
• The label low-code only half fits. Every one of these tools brings its own system with its own workflow logic, and that has to be learned. Anyone who knows automation from earlier days takes to it easily and is productive quickly. For everyone else it is new material, and in places actual programming is still required despite the label.
• A dependency arises. How strong it turns out varies from tool to tool: some hand out the workflows you built as a file, others keep them in house. Running what you built is as a rule only possible inside the tool itself, and that ties operations to the contract with the vendor.

A programming environment arrives at the same result in the end. The route there is a different one, and the difference only shows after the first project. What comes out of it is more than a script:

• scripts, meaning text files with work instructions that a computer processes in sequence;
• real programs and finished applications;
• agent workflows, in which an AI carries a task from start to finish;
• interfaces of your own to legacy systems, meaning docking points where 2 programs talk to each other.

The range is the actual point. A narrow frame is absent, and with it goes the limit on what can be built. The connection to a legacy system shows this most clearly. With a building-block tool it has to be programmed, unless it comes ready-made. In a programming environment it comes about in the same pass as everything else.

What you build then runs on its own, and that independence can be planned in deliberately. It can be independent of the environment the result was built in. The result sits in files that belong to you. And it can be independent of any single vendor. The same is achievable with a building-block solution, as far as we can see. The difference lies in the frame within which you build.

Communication instead of an interface

The great advantage of this way of working lies in what falls away: the rules of an interface, an unfamiliar workflow logic, strung-together boxes with rarely self-explanatory labels. What has to be learned is above all one thing, and it is exactly what an experienced manager already commands: communication. You say what you want to achieve. You check what comes back. And you work on the solution together. Anyone able to describe a task so clearly that a new employee carries it out without asking back already has the decisive skill.

Some technology is still involved, though. What remains is small and everyday: logging in, putting files in place and deciding what the AI may do in the case at hand. That last point matters most, because it stays with the human being. Anthropic states this explicitly for Claude Code. The environment holds exactly the rights you grant it. Reviewing what it proposes rests with the user. Granting such an approval is no harder, however, than signing off an invoice. You see what is meant to be done, and you decide.

This is a different kind of collaboration, and from our point of view the stronger one. The reason lies less in convenience than in the direction the tools are heading. The ability to describe a problem precisely gains in value. Knowing how to operate one particular interface loses a little of that value with every new version.

By contrast a building-block tool offers overview, an established approval practice and a contractual partner that IT has already vetted. Where IT prescribes such a tool, it has sound reasons, and a programme such as AIEE changes nothing about that. Even so, experiencing the other way of working first hand is worthwhile, and worthwhile before the decision on a larger undertaking comes up. Whoever knows both routes from personal experience decides on effort, lock-in and benefit with their own arguments rather than a vendor's.

This text describes how and why the server is used within the AIEE programme. The statements about WSL refer to the state as delivered, as documented by Microsoft; each of the bridges described can be closed with some effort. Which route suits an individual company depends on the requirements of its IT department, on the tools already in place and on the goal of the particular undertaking.