Sovereign AI Stack: Engineering Workshop

Not a presentation, but a working project tailored to your task:

• A working model for separating contours: red (only local models and self-hosted), yellow (Russian managed services) and green (permitted external reasoning models).
• A reference architecture by layer: client OS, dev workbench, Git platform, AI core, documents and office, agent layer, security and operations.
• A target stack design for your scenario and an implementation roadmap.
• A library of selection criteria — from the workstation to the model routing policy.

Guidelines by format; the depth of design and team composition are fixed before the start:

Expected result: in 2 days — a target stack design and contour boundaries; in 1–2 months — an approved roadmap and pilot layer; in 3–6 months — a deployed Russian AI contour for key data classes.

The main time is spent on designing based on participants' real scenarios, not on theory in short blocks.

1. Principles of a sovereign contour. Linux-first workstation, Git as the root of the engineering contour, routable AI instead of a "single window into a model."
2. Separating contours by data class. Red, yellow and green: what can be sent to which model and why.
3. Architecture layers. Workstation (Alt, Astra Linux), dev workbench (GigaIDE, SourceCraft), Git platforms (GitFlic, GitVerse), AI core (Yandex AI Studio, GigaChat, DeepSeek), documents (R7-Office, MyOffice, docs-as-code), agent bus and security layer.
4. Distributing models by task. Code and development, corporate search and knowledge base, documents and analytics, code review and engineering agents.
5. Target architecture options. A strict contour for critical infrastructure, a sovereign hybrid as the baseline scenario, and a flexible contour with permitted external APIs.
6. Implementation roadmap. Foundation (Linux, Git, data classification, docs-as-code), Russian AI core, contour separation and routing policy, agents and routine.
7. Review of participants' architectures. Diagnostics of the current stack and a transition plan taking into account company constraints. Artifact — target stack design.

• Engineering workshop: theory in short blocks, with the main time spent designing architecture based on real scenarios.
• A corporate project format is permitted: a team comes with its own stack and leaves with a roadmap.
• Constraints and assumptions are stated honestly: what is deployed locally, what is in a managed cloud, and what remains subject to policy approval.
• An engineering background is required and, preferably, a security/compliance representative on the team.

• CIOs, CTOs and architects — designing a Russian AI contour for a company or critical infrastructure.
• Heads of digital transformation and import substitution — who are leading the transition to a Russian stack.
• Engineers and DevOps — implementing local models and Git platforms.
• CISOs and compliance roles — who set requirements for contours and data.

We are an engineering and consulting collective that implements CRM, ERP, RPA and AI in real processes itself, including in critical and regulatorily sensitive environments. The workshop is built around manageability, not "complete rejection":

• Results through artifacts, not theory. Each module concludes with a scheme, selection criterion or roadmap that can be applied to your own stack.
• Routing instead of prohibition. We teach how to manage external models where policy permits, rather than proposing "everything in one API."
• Honest about limitations. We state what is deployed locally, what is in a managed cloud, and what requires separate approval and is not a legal opinion.
• We do not promise a "fully secure" stack. We promise a method and "before → after" verifiability: you will retain a design and a roadmap with contour boundaries.

Is this about banning external models? No. It is about managed routing: a Russian primary contour, with external models only in the green contour where data policy permits.

Do we need a strict critical infrastructure contour? Not necessarily. For most companies, the baseline scenario is a sovereign hybrid. A strict contour is required where there are direct requirements for isolation and placement.

We already work on a Western stack. Is this about complete rejection? The workshop provides a replacement table by layer and a roadmap: what to change first, what can be migrated gradually, and what requires separate approval.

Who should attend the program? The minimum composition is an architect or technical lead plus a security/compliance representative. Then the output will be not only a scheme, but also approved contour boundaries.

The format (open group or corporate project), participant composition, duration and cost are clarified upon request.

First step: enroll — we will send the terms, program and confirm the cohort date or the project work format for your team.

If you are unsure: send a brief description of your current stack, and at a free short review we will show which contour you need and where to start the transition.

Not relevant to the course at all? Start with the free cheat sheet for the red, yellow and green contours — how to separate data and prevent its leakage into the external contour.

[Enroll in a cohort] · [Request a free stack review] · [Download the contour scheme]

Should I come as a team or can I come alone?

You can come alone, but the program works best for a team: an architect or technical lead plus a security/compliance representative. Then the output is not only a scheme, but also approved contour boundaries.

What access and data are needed for the workshop?

A description of the current stack and data classes is sufficient. Real sensitive data is not loaded into the training contour — the review is based on anonymized scenarios and your architectural scheme.

Will the program work if we have a hybrid Western stack?

Yes. The workshop provides a replacement table by layer and a roadmap: what to change first, what can be migrated gradually, and what requires separate approval from security and compliance.

Do you provide a ready-made "turnkey" architecture?

No, and this is deliberate. We design together with your team: the output is a target stack design, selection criteria and a roadmap that you understand and can defend within the company.

How are 152-FZ and critical infrastructure requirements taken into account in the program?

Contour separation is built around data classes and regulatory constraints: what remains local, what goes to a managed Russian cloud, and what is permitted in the external contour only by policy. This is engineering logic, not a legal opinion.

• Training and acceleration — if you need to build AI competencies across an entire team.
• AI consulting — if you further need a review of AI/automation implementation in a specific process.
• Courses and training — the full catalog of programs.
• Blog on learning and competencies — how to train a team and not lose the result.