Trục 1: Nền tảng

Tuân thủ Git-native

Luận điểm cốt lõi của GCBoK:

Tuân thủ Git-native có nghĩa là tất cả cácArtifact tuân thủ, quyết định, định danh và bằng chứng sống chính trong kho Git — có phiên bản, ký bằng GPG, máy đọc được bằng OSCAL, kiểm chứng bằng OPA — mà không cần kho tuân thủ thứ cấp.

Phân loại trong phổ paradigm

Paradigm	Lĩnh vực	Nguồn sự thật
Cloud-native	Hạ tầng	CNCF
GitOps	Triển khai	OpenGitOps Working Group
Tuân thủ Git-native	Tuân thủ	GCBoK

Ba trụ cột của tuân thủ Git-native

1. Neo mật mã — Mỗi mục nhập trong kho Git được bảo mật bằng hash, tùy chọn với chữ ký GPG. Như vậy chứng minh được: Ai, Cái gì, Khi nào. Điều này đáp ứng yêu cầu GoBD về tính không thay đổi — nhưng tự nhiên thông qua kiến trúc Git.

2. Tính máy đọc được — OSCAL (Open Security Controls Assessment Language) cho kiểm soát an ninh và kết quả đánh giá. OPA/Rego (Open Policy Agent) cho quy tắc tuân thủ dưới dạng mã, tự động kiểm tra trạng thái Git.

3. Tính tất định qua V7GUID — Mỗi đối tượng tuân thủ có địa chỉ duy nhất toàn cầu (UUIDv7), sắp xếp theo thời gian (timestamp 48-bit), phân loại được (identifier lớp 14-bit) và có thể nối thành chuỗi chứng từ.

Tự tham chiếu không Vendor Lock-In

Tuân thủ Git-native là tự tham chiếu: tất cả các thành phần GitCover — nguồn, tham chiếu, biện pháp, tài liệu — được định địa chỉ và quản lý duy nhất thông qua các kho Git. Sự thật nằm trong chính .git (commit, tree, hash), không phải trong dịch vụ bên ngoài, wiki hay ticket. Điều này tránh Vendor Lock-In: mỗi kho, tự thân, có thể kiểm toán bản sửa đổi, di động và không phụ thuộc độc quyền.

Tiêu chuẩn hash: luôn SHA-256, không bao giờ SHA-1

Mỗi kho GitCover được tạo với SHA-256 làm hàm băm đối tượng (git init --object-format=sha256 hoặc extensions.objectformat = sha256). SHA-1 bị cấm rõ ràng (các cuộc tấn công va chạm). Sự neo mật mã (trụ cột 1) do đó xây dựng trên một tiêu chuẩn hash được chứng minh an toàn.

Vị trí của các công cụ GitCover

Tất cả công cụ, dịch vụ GitCover và (trong tương lai) MCP-server được đặt, theo kế hoạch, dưới /opt/GitCover/ (ví dụ CLI WebStaticBuilder dưới /opt/GitCover/webstatic). Điều này tránh lưu trữ hệ thống không có phiên bản. Sau khi onboarding, /opt/GitCover tự nó trở thành một kho Git ghi chép có phiên bản các tham số môi trường tuân thủ GoBD (BASE_URL, CDN, đường dẫn, phiên bản công cụ).

Tuân thủ như hạ tầng

GitCover không phải công cụ cho người đam mê tuân thủ. Nó là hạ tầng cho tất cả những ai muốn hoàn thành tuân thủ. Điều đó có nghĩa:

Chi phí thấp nhất có thể — Open Source, không giấy phép độc quyền
Bảo mật tối đa — Neo mật mã, không thông qua lớp phần mềm
Tính chứng minh đầy đủ — Lịch sử Git làm audit-trail tích hợp sẵn

Mô hình kiến trúc: Ứng dụng chuyên ngành dọc và backbone tuân thủ ngang

flowchart TB subgraph HorizotalBackbone["Horizontaler GitCover® Compliance-Backbone"] GitCover["Git Repos/Features · TOP · PII · OSCAL · OPA · GPG · V7GUID · etc."]:::coverBar end subgraph VertikaleAnwendungen["Vertikale Fachanwendungen (Beispiele)"] direction TB FiBu["Finanzbuchhaltung"] Zeit["Zeiterfassung"] Lohn["Lohnabrechnung"] Mails["Geschäftskorrespondenz"] OPos["E-Rechnung Eingang/Ausgang"] end FiBu <-->|"Revisionssichere Ablage
Beleg-Ketten"| GitCover Zeit <-->|"Policy-Validierung"| GitCover Lohn <-->|"SV/AO/GoBD-Nachweise"| GitCover Mails <-->|"E-Mail-Archivierung"| GitCover OPos <-->|"XML-Daten, Audit-Trails"| GitCover subgraph KISchicht["KI-Agenten-Ebene"] Agent["KI-Compliance-Agent
(eingesperrt im Worktree)"]:::agentBar end Agent -->|"liest/schreibt
nur im zugewiesenen Repo"| GitCover Agent -.->|"OPA-Guardrails
als Pre-Receive-Hooks"| GitCover classDef coverBar fill:#6B7280,color:#FFFFFF,stroke:#4B5563,stroke-width:2px,rx:6,ry:6,min-width:100%,font-size:1.1em,padding:6px,margin:6px; classDef agentBar fill:#0A7F5C,color:#FFFFFF,stroke:#0A7F5C,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px,margin:4px;

Cách đọc: Các ứng dụng chuyên ngành dọc (kế toán, chấm công, tính lương, ERP, kho) giữ độc lập về nội dung và tự chủ về chuyên môn. GitCover tạo lớp ngang: kho Git làm backbone tuân thủ xuyên suốt, kết nối mỗi ứng dụng dọc với catalog OSCAL, chính sách OPA, chữ ký GPG và chuỗi chứng từ V7GUID — không cần middleware độc quyền và không cần kho tuân thủ thứ cấp.

Khuôn khổ pháp lý

GCBoK giải quyết các khuôn khổ quản lý sau:

GoBD — Grundsätze ordnungsmäßiger DV-gestützter Buchhaltungssysteme (Nguyên tắc hệ thống kế toán điện tử đúng đắn)

GoBD (Rz. 151-157) yêu cầu hệ thống kiểm soát nội bộ, tính truy vết, tính không thay đổi và tính đúng thời gian. Tuân thủ Git-native đáp ứng các yêu cầu này một cách tự nhiên:

Yêu cầu GoBD	Đáp ứng Git-native
Tính truy vết	Lịch sử Git (commit-log)
Tính không thay đổi	Hash Git + chữ ký SSH-/GPG
Tính đúng thời gian	Timestamp V7GUID (UUIDv7)
Hệ thống kiểm soát nội bộ	Chính sách OPA làm pre-receive-hooks

NIS2 — Network and Information Security Directive (Chỉ thị an ninh mạng và thông tin)

Chỉ thị EU-NIS2 yêu cầu quản lý rủi ro và nghĩa vụ báo cáo cho hạ tầng trọng yếu. GCBoK định nghĩa phương pháp phân tích rủi ro NIS2 dựa trên kho Git.

BSI GS++ & GCBoK Compliance-as-Code

Sổ tay BSI IT-Grundschutz (Bảo vệ cơ bản IT) định nghĩa tiêu chuẩn cho an ninh thông tin và ngày càng cung cấp chúng ở định dạng máy đọc được (như OSCAL). GCBoK sử dụng các catalog OSCAL chuẩn hóa này và map trực tiếp các kiểm soát BSI sang quy trình tuân thủ Git-native tự động (Compliance-as-Code). Nó chuyển đổi các yêu cầu quản lý của BSI thành quy trình kiểm tra khả thi hóa trong hệ sinh thái GitCover.

DSGVO — Datenschutz-Grundverordnung (Quy định bảo vệ dữ liệu chung của EU)

DSGVO yêu cầu Privacy by Design (Bảo vệ quyền riêng tư theo thiết kế). GCBoK định nghĩa bằng chứng định danh phi tập trung (cũng như định danh PGP), neo dữ liệu cá nhân không trong cơ sở dữ liệu trung tâm mà trong cấu trúc Git.

Hiểu biết ứng dụng

Các nguyên tắc kiến trúc của GCBoK phải dễ tiếp cận với người dùng có ít kiến thức IT. Phần này truyền đạt các mô hình tâm lý giúp việc làm việc với tuân thủ Git-native trở nên dễ hiểu cho người ngoài chuyên môn.

Files over Apps — Nguyên tắc dẫn dắt

GCBoK tuân theo nguyên tắc dẫn dắt Files over Apps (Tệp hơn Ứng dụng): cácArtifact tuân thủ sống dưới dạng tệp trong kho Git, không trong cơ sở dữ liệu ứng dụng độc quyền. Các cuộc trò chuyện, tài liệu, chứng từ và chính sách là tệp Markdown, YAML hoặc JSON trong Git-tree — có phiên bản, có thể ký, có thể kiểm toán. Ứng dụng có thể thay đổi; tệp thì bền vững.

Điều này khác biệt căn bản với paradigm ứng dụng cổ điển, nơi phần mềm giữ dữ liệu trong cơ sở dữ liệu riêng và việc xuất dữ liệu là nhu cầu sau đó. Với tuân thủ Git-native, xuất dữ liệu là trạng thái bình thường.

Hồ sơ kỹ thuật số — Mô hình tâm lý

Đối với người dùng ít kiến thức máy tính, khái niệm toàn bộ hệ thống tệp là trừu tượng và dễ sai. Ẩn dụ hồ sơ kỹ thuật số giải quyết vấn đề này:

Thư mục làm việc Git không phải một thư mục PC lộn xộn, mà là một hồ sơ kỹ thuật số có máy sao chép và sổ ghi chép tích hợp (Git).
Quy tắc: Một AI-agent chỉ được đọc và viết trong thư mục cụ thể này. Mọi thứ bên ngoài không tồn tại với nó.
Tính hiển thị: Mỗi thay đổi AI thực hiện được đánh dấu ngay lập tức (Git-status). Người ngoài chuyên môn thấy: "AI đã thay đổi dòng 4 trong tài liệu quy trình."
Tính bảo mật: Git staging-area trở thành cửa sổ xem trước và phê duyệt. Người dùng không cần hiểu Git — họ hiểu nguyên lý: "AI đề xuất một thay đổi, tôi nhấp Chấp nhận (Commit)."

Nguyên tắc hộp cát

Để tuân thủ GoBD và NIS2, việc giới hạn phạm vi truy cập là cơ bản. Một AI-agent chỉ có thể truy cập thư mục làm việc Git được gán thì bị nhốt vật lý:

Ngay cả khi agent bị hallucinate hoặc bị thao túng qua prompt-injection, nó không thể thoát khỏi kho Git.
Giải thích cho người dùng: "AI bị nhốt trong thư mục dự án này. Nó không thể gây hại cho phần còn lại của hệ thống."
Mỗi hoạt động tuân thủ được tài liệu hóa trong lịch sử Git làm lưới an toàn — người dùng giữ đầy đủ chủ quyền.

So sánh môi trường làm việc AI

GCBoK trung lập về công nghệ đối với môi trường làm việc AI. Ba paradigm để lựa chọn:

Tiêu chí	WebUI-first (Trình duyệt)	Desktop-Client (App native)	Nền tảng All-in-One
Paradigm	Proxy cấp OS, truy cập hệ thống tệp qua trình duyệt	Client-first, điều phối agent cục bộ/SSH	Workspace đầy đủ (chat, mail, tài liệu, lịch)
Tiêu điểm	Quản lý tệp, Git-staging, terminal qua trình duyệt	Hệ sinh thái agent, skill-store, multi-agent	Hub năng suất, thay thế SaaS cục bộ/riêng
Sandbox	Docker bind-mounts, cô lập Git-worktree	API-gating, token-limits, quyền cục bộ	Docker-container, cô lập
Ưu điểm	Tích hợp Git liền mạch, Files over Apps	Hiệu năng cao, tích hợp công cụ chặt	Mạnh mẽ, mọi tác vụ văn phòng trong một giao diện
Nhược điểm	Mô hình bảo mật yêu cầu cấu hình mount cẩn thận	Cấu hình yêu cầu hiểu biết kỹ thuật	Hạ tầng Docker, dữ liệu bị ràng buộc trong DB riêng
Phù hợp GCBoK	Rất cao — chính xác "Files over Apps"	Trung bình — rào cản cấu hình cho người ngoài chuyên môn	Thấp — dữ liệu không được lưu Git-native

Khuyến nghị: Mô hình thiết bị lai

Cho người dùng DNVV không có kiến thức IT sâu, GCBoK khuyến nghị mô hình thiết bị lai:

Đóng gói hạ tầng (trung tâm): Một máy chủ AI headless trong LAN đảm nhận LLM-inference và quản lý Git. Độ phức tạp được chuyển hoàn toàn đến đó.
Máy trạm client tối thiểu: Người dùng cuối không cần Docker cục bộ, không cần Python và không cần Git trên desktop. Họ truy cập duy nhất qua trình duyệt (như PWA) vào giao diện web.
Luồng tương tác: Người dùng sử dụng chức năng chat và ghi chú. Khi muốn kiểm tra hoặc tạo tài liệu tuân thủ, AI-agent làm việc nền trực tiếp trên thư mục của file-server trung tâm. Agent đảm nhận staging, commit và push vào kho Gitea — người dùng thấy một checklist trực quan trong UI.

Mục tiêu: Người dùng không trải nghiệm "AI điều khiển máy tính", mà một chuyên viên xử lý thông minh cho thư mục tuân thủ cụ thể. Họ biết AI làm việc ở đâu, thấy mỗi bước trong lịch sử Git và giữ đầy đủ chủ quyền mà GCBoK yêu cầu.

Kiến trúc tham chiếu: Mô hình thiết bị lai

flowchart TB subgraph Client["Client-Ebene (minimal)"] Browser["Browser / PWA
kein Docker, kein Git lokal"]:::clientBar end subgraph KIServer["KI-Server im LAN (headless)"] OWUI["Web-Oberfläche
(Chat + Notizen)"]:::serverBar Agent["KI-Agent
(im Git-Worktree eingesperrt)"]:::agentBar Ollama["LLM-Inferenz
(Ollama, lokal)"]:::serverBar end subgraph FileServer["File-Server / Git-Host"] Gitea["Gitea
(Git-Repositories + IdP)"]:::storageBar Repos["Git-Working-Directories
pro Mandant isoliert"]:::storageBar end Browser -->|"HTTPS"| OWUI OWUI --> Agent Agent -->|"liest/schreibt
nur im zugewiesenen Worktree"| Repos Agent -->|"LLM-Anfrage"| Ollama Agent -->|"Commit + Push"| Gitea Gitea --- Repos classDef clientBar fill:#2563EB,color:#FFFFFF,stroke:#1D4ED8,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px; classDef serverBar fill:#6B7280,color:#FFFFFF,stroke:#4B5563,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px; classDef agentBar fill:#0A7F5C,color:#FFFFFF,stroke:#0A7F5C,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px; classDef storageBar fill:#92400E,color:#FFFFFF,stroke:#78350F,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px;

Xem thêm: Việc thực hành các khuôn khổ này được mô tả trong Trục 5: Quy trình.