Trợ Lý Pháp Lý AI — Sổ Tay Vận Hành

Dành cho team Nhân sự

Hệ thống hoạt động thế nào và làm được gì

Một trợ lý biết đọc luật Việt Nam và đọc hợp đồng của công ty. Giao diện dùng qua trình duyệt, bố cục ba cột: trái là cây thư mục tài liệu, giữa là nội dung, phải là khung trò chuyện.

Luồng xử lý khi bạn đặt một câu hỏi

1Bạn gõ câu hỏi bằng tiếng Việt tự nhiên

↓

2Hệ thống đoán chủ đề: lao động · thuế · doanh nghiệp · dân sự · đất đai…

↓

3Mở rộng từ viết tắt — BHXH → bảo hiểm xã hội, HĐLĐ → hợp đồng lao động

↓

4Tìm trong kho văn bản luật cùng tài liệu nội bộ công ty

↓

5Gửi kết quả tìm được kèm câu hỏi cho mô hình AI

↓

6AI tự quyết định cần dùng công cụ nào, dùng bao nhiêu lần

↓

7Trả lời, hiển thị dần từng chữ theo thời gian thực

Điểm mấu chốt: AI tự chọn công cụ

Đây không phải chatbot hỏi–đáp thông thường. Hệ thống trao cho AI một bộ 25 công cụ và để AI tự quyết định dùng cái nào, theo thứ tự nào.

Ví dụ khi bạn hỏi “Hợp đồng thử việc của bạn Minh có đúng luật không?”, AI tự động:

Gọi liệt kê hợp đồng để tìm hồ sơ của Minh
Gọi đọc hợp đồng để lấy nội dung
Gọi tra cứu luật để lấy quy định về thời gian thử việc
Gọi kiểm tra tuân thủ để đối chiếu
Tổng hợp và trả lời

Bạn không cần biết các bước này — chỉ cần hỏi.

Bộ máy tìm kiếm luật

Tìm kiếm chạy qua sáu lớp để không bỏ sót:

Lớp	Cách làm
Nhận diện chủ đề	Dựa vào từ khoá trong câu hỏi để thu hẹp phạm vi
Khôi phục dấu	Gõ “hop dong lao dong” vẫn ra “hợp đồng lao động”
Mở rộng viết tắt	BHXH · BHYT · TNCN · GTGT · NLĐ · NSDLĐ đều được hiểu
Tìm cụm chính xác	Ưu tiên kết quả khớp nguyên cụm từ
Tìm toàn văn	Mở rộng khi lớp trên cho ít kết quả
Xếp hạng	Sắp kết quả theo mức độ liên quan

Hệ thống hiểu cả từ đồng nghĩa dân dã: “đuổi việc” và “sa thải” đều dẫn về kỷ luật sa thải, “phép năm” dẫn về nghỉ hằng năm.

Trí nhớ về công ty

Hệ thống ghi nhớ bối cảnh doanh nghiệp — lĩnh vực hoạt động, quy mô, các quy định nội bộ đã trao đổi. Càng dùng lâu, câu trả lời càng sát đặc thù công ty, và bạn không phải giải thích lại từ đầu mỗi phiên.

Bộ 25 công cụ

Tra cứu pháp luật

Tra cứu luật	Tìm trong kho văn bản pháp luật Việt Nam
Thu thập văn bản	Lấy thêm văn bản luật mới từ nguồn trên mạng

Hợp đồng

Liệt kê hợp đồng	Xem danh sách hợp đồng đang lưu
Đọc hợp đồng	Mở nội dung một hợp đồng cụ thể
Phân tích rủi ro	Chấm điểm rủi ro, chỉ ra điều khoản nguy hiểm
Rà soát bằng AI	Phân tích sâu: điểm tốt, điểm thiếu, khuyến nghị sửa
Tóm tắt hợp đồng	Các bên, giá trị, thời hạn, nghĩa vụ chính
So sánh hợp đồng	Đối chiếu hai hợp đồng, làm nổi phần khác biệt
Kiểm tra tuân thủ	Đối chiếu hợp đồng với luật hiện hành
Rà soát hàng loạt	Xử lý nhiều hợp đồng cùng lúc

Soạn thảo

Soạn văn bản	Tạo hợp đồng, quyết định, thông báo từ mẫu
Sinh điều khoản	Bảo mật, phạt vi phạm, chấm dứt, bất khả kháng…
Tạo tài liệu	Sinh tài liệu mới theo yêu cầu
Sửa tài liệu	Chỉnh sửa nội dung có sẵn
Sửa & xem khác biệt	Sửa xong hiện ngay phần thay đổi để bạn duyệt

Quản lý tài liệu & bối cảnh

Liệt kê · Đọc · Ghi tài liệu	Thao tác cơ bản với kho tài liệu
Tạo thư mục · Di chuyển · Xoá	Sắp xếp kho tài liệu
Lịch sử tài liệu	Xem phiên bản trước, ai sửa lúc nào
So sánh tài liệu	Đối chiếu hai tài liệu bất kỳ
Tìm trong tài liệu công ty	Tìm kiếm trong kho nội bộ
Hồ sơ công ty	Lấy thông tin doanh nghiệp làm bối cảnh trả lời

Tám mẫu hợp đồng có sẵn

Điền thông tin tự động, team HR dùng nhiều nhất là hai mẫu đầu:

Hợp đồng lao động
Thoả thuận bảo mật thông tin (NDA)
Hợp đồng dịch vụ · mua bán · thuê mặt bằng
Hợp đồng đại lý · hợp tác kinh doanh · vay

Phân quyền — ai làm được gì

Bốn cấp, cấp cao bao gồm quyền của cấp thấp:

Cấp	Quyền hạn
Người xem	Đọc hợp đồng và tài liệu, hỏi đáp với trợ lý
Thành viên	Thêm: tải lên, sửa, soạn thảo tài liệu
Quản trị	Thêm: quản lý người dùng, xem toàn bộ nhật ký hoạt động
Chủ sở hữu	Toàn quyền: cấu hình mô hình AI, khoá API, thanh toán

Gợi ý phân vai

Trưởng phòng Nhân sự ở cấp Quản trị, chuyên viên ở cấp Thành viên, các phòng ban khác cần tra cứu thì cấp Người xem. Tài khoản đầu tiên đăng ký tự động trở thành Chủ sở hữu.

Giới hạn kỹ thuật

Hạng mục	Giới hạn
Định dạng tệp nhận	PDF · DOC · DOCX · TXT · XLSX · XLS · JPG · JPEG · PNG
Dung lượng mỗi tệp	Tối đa 50 MB
Tải lên một lần	Tối đa 10 tệp
Phân tích hàng loạt	Tối đa 20 hợp đồng cùng lúc
Mật khẩu tài khoản	Từ 10 ký tự, có chữ HOA, chữ thường, số và ký tự đặc biệt
Số lần đăng ký	3 lần / 10 phút cho mỗi email

Cảnh báo bắt buộc đọc

Giá trị pháp lý

Đây là công cụ hỗ trợ, không thay thế luật sư.

Mọi kết quả AI đưa ra phải có người rà soát lại trước khi ký, gửi ra ngoài, hoặc dùng làm căn cứ kỷ luật.
Với quyết định quan trọng — chấm dứt hợp đồng, tranh chấp lao động, thanh tra — bắt buộc tham khảo luật sư.
AI có thể trích dẫn sai điều luật hoặc dẫn văn bản đã hết hiệu lực. Luôn mở phần trích dẫn kiểm tra văn bản gốc.
Kho luật có thể chưa cập nhật nghị định, thông tư mới nhất.

Bảo mật dữ liệu

Nội dung hợp đồng được gửi tới nhà cung cấp mô hình AI để xử lý. Cân nhắc kỹ với dữ liệu đặc biệt nhạy cảm: lương ban lãnh đạo, hồ sơ kỷ luật, thông tin sức khoẻ.
Không chia sẻ tài khoản. Hệ thống ghi nhật ký theo người dùng — dùng chung là mất dấu vết.
Không dán khoá API vào khung chat. Khoá chỉ nhập ở trang Cài đặt, nơi nó được mã hoá.
Mọi thao tác đều vào nhật ký hoạt động — quản trị viên xem được ai đọc, sửa, xoá gì.

Vận hành

Xoá tài liệu là vĩnh viễn — không có thùng rác.
Bản quét chất lượng kém cho kết quả kém. Ưu tiên tệp gốc Word hoặc PDF chữ.
Kiểm tra lại số liệu. AI đôi khi nhầm ngày tháng, số tiền, tỷ lệ phần trăm khi tóm tắt.
Hỏi càng cụ thể càng tốt: “Thời gian thử việc tối đa cho vị trí kế toán trưởng?” tốt hơn nhiều so với “hỏi về thử việc”.

Dành cho team Dev

Nhật ký chuyển repo và deploy — sai sót & bài học

Toàn bộ quá trình đưa dự án từ repo gốc về Mắt Bão, gồm bảy sự cố đã gặp. Ghi lại để lần sau không lặp lại, vì phần lớn chúng cùng chung một gốc rễ.

Bước chuyển repo

Giữ nguyên toàn bộ lịch sử, đồng thời giữ đường về repo gốc để cập nhật sau này:

git clone https://github.com/Paparusi/legal-ai-agent.git
cd legal-ai-agent

git remote rename origin upstream                 # repo gốc tác giả
git remote add origin https://github.com/HThanh209/Ph-p-l-HR.git

git push -u origin main

Muốn đồng bộ code mới từ tác giả gốc về sau: git fetch upstream rồi git merge upstream/main.

Ghi nhận khi push

GitHub cảnh báo data/uts_vlc_processed.json nặng 62 MB, vượt mức khuyến nghị 50 MB. Push vẫn qua, nhưng nếu file này còn thay đổi thì nên chuyển sang Git LFS.

Bảy sự cố đã gặp

01 App sập khi khởi động — khoá Fernet sai định dạng Gốc rễ Đã sửa

Triệu chứng: Health Check thất bại, app không kịp mở cổng 8080.
Nguyên nhân: LLM_ENCRYPTION_KEY được đặt bằng chuỗi tự nghĩ. Fernet đòi base64 url-safe đúng 32 byte, và dòng khởi tạo nằm ở cấp module nên ValueError ném ra ngay lúc import.
Bẫy: Biến này có trong README nhưng thiếu hẳn trong .env.example — người deploy không thấy, đoán rằng chuỗi ngẫu nhiên nào cũng được.
Đã sửa: Key sai giờ chỉ ghi cảnh báo rồi suy ra khoá ổn định từ SECRET_KEY, app vẫn khởi động. Bản cũ còn tệ hơn: nó sinh khoá ngẫu nhiên mỗi lần khởi động, khiến mọi khoá API đã lưu hỏng sau mỗi lần restart mà không ai hiểu vì sao.

02 404 khi mở /static/app.html Hiểu nhầm Đã rõ

Nguyên nhân: Ứng dụng chính phục vụ ở đường dẫn /app, không phải /static/app.html.
Đường dẫn đúng: / trang giới thiệu · /app ứng dụng chính · /platform-admin quản trị · /docs tài liệu API · /health tình trạng

03 Tên biến môi trường lệch nhau — gốc rễ của phần lớn sự cố Gốc rễ Đã sửa

Ba biến quan trọng có tên trong tài liệu khác hẳn tên mà mã nguồn thực sự đọc. Đặt đúng theo tài liệu vẫn không có tác dụng gì, và không có thông báo lỗi nào:

Bạn đặt	Code thật đọc	Hậu quả
`POSTGRES_*`	`SUPABASE_DB_*`	Cấu hình DB bị bỏ qua, rơi về `localhost`
`JWT_SECRET`	`SUPABASE_JWT_SECRET`	Khoá JWT chưa từng có tác dụng, app chạy bằng khoá mặc định yếu
—	`LLM_ENCRYPTION_KEY`	Không có trong `.env.example`, điền bừa là sập

Đã sửa: thống nhất về một bộ DB_HOST · DB_PORT · DB_NAME · DB_USER · DB_PASSWORD · DB_SSL_MODE, áp dụng cho toàn bộ 15 module có kết nối database. .env.example viết lại cho khớp.

04 Đăng ký thất bại — thực chất là lỗi database Chẩn đoán sai Đã sửa

Triệu chứng: Giao diện báo cụt lủn “Đăng ký thất bại”, console hiện lỗi 404.
Chẩn đoán sai: Lỗi 404 kia là của tài nguyên khác — icon hoặc manifest — không phải của lệnh đăng ký. Kiểm tra /openapi.json xác nhận /v1/auth/register vẫn tồn tại.
Nguyên nhân thật: /health báo "database":"error" — app không nối được PostgreSQL.
Đã sửa: /health giờ trả thêm db_state phân biệt rõ connect_failed với connected_missing_schema — hai lỗi cần cách chữa ngược nhau.

05 Dockerfile không copy thư mục database/ Gốc rễ Đã sửa

Dockerfile copy src/, static/, scripts/, data/ nhưng bỏ sót database/. Nghĩa là init.sql — file chứa toàn bộ lược đồ 24 bảng — không tồn tại trong image. Dù chạy migration bằng cách nào cũng không thể thành công.

06 DATABASE_URL chỉ được đọc một nửa hệ thống Gốc rễ Đã sửa

DATABASE_URL ban đầu chỉ được phần tạo lược đồ đọc, còn bản thân ứng dụng đọc DB_HOST/DB_PORT. Nếu chỉ đặt chuỗi URI, kết quả sẽ là: bảng tạo xong hết, nhưng app vẫn báo lỗi database — không có gì gợi ý tại sao.

Đã sửa: gom về một module cấu hình duy nhất, cả bốn chỗ kết nối đều đi qua đó. Đặt DATABASE_URL là đủ; khi có nó, các biến DB_* bị bỏ qua hoàn toàn.

07 JWT_SECRET ngắn hơn 32 ký tự khi bật ENV=production Cấu hình Đã xử lý

Ba điều kiện, vi phạm bất kỳ cái nào là app sập ngay lúc import:

if not JWT_SECRET or "change-in-production" in JWT_SECRET or len(JWT_SECRET) < 32:
    if os.getenv("ENV", "development") == "production":
        raise ValueError("CRITICAL: Set a strong JWT_SECRET in production!")

Không nới lỏng kiểm tra này

Chặn khoá JWT yếu ở môi trường thật là hành vi đúng, càng cần thiết với ứng dụng chứa hợp đồng lao động và dữ liệu nhân sự. Khác với sự cố 01 — chỗ đó sập là vô lý vì chỉ ảnh hưởng một tính năng phụ. Sửa khoá, đừng sửa luật.

Bảy quy tắc rút ra

Tin mã nguồn, đừng tin tài liệu Trước khi đặt biến môi trường, hãy tìm trong code xem nó đọc tên gì: grep -r "os.getenv" src/. Ba sự cố nặng nhất đều sinh ra từ việc tài liệu và code nói hai thứ khác nhau.

Đừng tin chẩn đoán tự động, kể cả của công cụ deploy vibehost chỉ đúng hiện tượng nhưng sai biến ở sự cố đầu tiên — nó đổ cho SECRET_KEY/JWT_SECRET trong khi thủ phạm là LLM_ENCRYPTION_KEY. Luôn đối chiếu lại với mã nguồn.

Không nuốt lỗi bằng except Exception Một chữ "error" gộp hai nguyên nhân cần cách chữa ngược nhau đã làm mất nhiều thời gian nhất. Lỗi phải nói được nó là lỗi gì.

Khởi tạo ở cấp module là bom hẹn giờ Cấu hình sai ở cấp module làm app chết trước khi mở cổng, kéo theo mất luôn /health — đúng cái endpoint dùng để chẩn đoán. Tính năng phụ hỏng thì ghi log, đừng sập cả hệ thống.

Health check phải thật sự kiểm tra Endpoint /health nguyên bản trả {"status":"healthy"} cứng, không đụng tới database. “Health Check pass” của hạ tầng vì thế không chứng minh được gì.

Kiểm tra Dockerfile copy đủ thứ cần Thiếu một dòng COPY là cả một thư mục biến mất khỏi image, mà lỗi chỉ lộ ra lúc chạy.

Siết bảo mật sẽ làm lộ ra nợ cũ Bật ENV=production khiến app sập vì khoá yếu. Đó là tiến triển tốt, không phải bước lùi — nên bật sớm để lộ vấn đề sớm.

Mức độ kiểm chứng của các bản sửa

Cần biết khi đọc lại nhật ký này

Máy phát triển không có Python lẫn Docker, nên phần lớn thay đổi được rà bằng đọc mã và tìm kiếm toàn kho, chứ không chạy thử.

Có kiểm chứng: bộ tách câu lệnh SQL và nhánh xử lý khi thiếu pgvector — cài lại thuật toán bằng PowerShell rồi chạy trên chính hai file migration thật.
Việc kiểm chứng đó bắt được một lỗi thật: biểu thức nhận diện bỏ sót CREATE EXTENSION IF NOT EXISTS "vector" vì có IF NOT EXISTS chen giữa.
Chưa kiểm chứng bằng thực thi: phần đổi tên biến, file_storage.py, bản vá Fernet. Chúng được xác nhận gián tiếp qua việc hệ thống chạy được trên vibehost.

Cảnh báo ngoài phạm vi dự án

Thư mục HThanhCode đang là repo sales-dashboard

Thư mục C:\Users\thanhdh2\Documents\HThanhCode là repo HThanh209/sales-dashboard, nhưng đã vô tình chứa toàn bộ các dự án khác. Không commit ở đây. Hậu quả nếu commit:

Khoảng 2,5 GB gồm 9 dự án khác bị đẩy vào repo dashboard bán hàng — NhacViec 479 MB, Dashboard MBI 441 MB, Dashboard-MBI-Test 432 MB, Monitor-MBI 328 MB, Matbao All 307 MB, TamQuoc-Game 271 MB, hddt 137 MB…
Rò rỉ 6 file .env chứa mật khẩu database và khoá API thật. Đẩy lên GitHub là coi như đã lộ, kể cả khi xoá ngay sau đó — vẫn nằm trong lịch sử git.
Hỏng 6 repo git con lồng bên trong.

Cách xử lý gọn: thêm .gitignore tại HThanhCode để git ngừng nhìn thấy các thư mục dự án khác. Repo legal-ai-agent thì hoàn toàn sạch, không liên quan.

Dành cho team Dev

Vận hành trên vibehost Mắt Bão

Kiến trúc sau khi gỡ bỏ hoàn toàn Supabase, danh sách biến môi trường chuẩn, và quy trình deploy cho mô hình autodeploy từ git.

Vì sao gỡ Supabase và đã gỡ những gì

Dự án gốc thiết kế cho Supabase. Mắt Bão đã có sẵn PostgreSQL 16 trên tinhgon, nên giữ lại Supabase chỉ tạo thêm một lớp tên gọi gây nhầm lẫn — chính là nguồn gốc của sự cố 03.

Hạng mục	Xử lý
Tên biến `SUPABASE_DB_*`	Đổi thành `DB_*` trên 15 module
`SUPABASE_JWT_SECRET`	Đổi thành `JWT_SECRET`
Supabase Storage	Chuyển sang lưu đĩa thuần, thêm biến `UPLOAD_DIR`
URL Supabase hardcode	Gỡ bỏ — nó trỏ tới dự án Supabase của người khác
7 file phụ thuộc Supabase	Xoá. Thư viện `supabase` vốn không có trong `requirements.txt` nên chưa từng chạy được
`GOOGLE_API_KEY`	Xoá — không dòng code nào đọc; khoá Gemini nhập qua giao diện Cài đặt

Kết quả

Quét toàn kho: không còn dòng nào nhắc Supabase. Tổng cộng 39 file được sửa, 7 file xoá.

Biến môi trường chuẩn trên vibehost

Database — chọn một trong hai cách

# Cách 1 — gọn nhất, một biến duy nhất
DATABASE_URL=postgresql://user:password@HOST-NOI-BO:5432/dbname

# Cách 2 — khai báo từng phần
DB_HOST=<Host nội bộ>
DB_PORT=<Port nội bộ>
DB_NAME=<Database name>
DB_USER=<Username>
DB_PASSWORD=<Password>
DB_SSL_MODE=prefer

Dùng Host nội bộ, không dùng tinhgon.xyz

Ứng dụng và database nằm cùng hạ tầng, đi đường nội bộ sẽ nhanh hơn và không phơi database ra Internet. Chuỗi URI mà vibehost cho sẵn ở mục CONNECTION STRINGS thường trỏ tới Host bên ngoài — dán nguyên si là vô tình đi vòng ra Internet.

DATABASE_URL khi có mặt sẽ đè lên toàn bộ DB_*. Nếu DB_* đã chạy đúng thì đừng thêm nó — không lợi ích gì, chỉ thêm một chỗ có thể sai.

Ứng dụng và bảo mật

APP_PORT=8080
ENV=production
UPLOAD_DIR=/app/uploads/documents
ALLOWED_ORIGINS=https://phaplyhr.tinhgon.xyz

SECRET_KEY=<chuỗi ngẫu nhiên dài>
JWT_SECRET=<tối thiểu 32 ký tự — dưới mức này app sẽ không khởi động>
LLM_ENCRYPTION_KEY=<khoá Fernet, base64 url-safe, đúng 44 ký tự>
API_KEY_SECRET=<chuỗi ngẫu nhiên>

ANTHROPIC_API_KEY=<khoá Claude>

Sinh các khoá bí mật:

# Khoá Fernet cho LLM_ENCRYPTION_KEY
python -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())"

# SECRET_KEY, JWT_SECRET, API_KEY_SECRET
python -c "import secrets; print(secrets.token_urlsafe(48))"

Ba biến bắt buộc đúng định dạng

JWT_SECRET — tối thiểu 32 ký tự, không chứa chuỗi change-in-production. Vi phạm khi ENV=production là app sập ngay lúc khởi động.
LLM_ENCRYPTION_KEY — đúng 44 ký tự, base64 url-safe. Không tự nghĩ chuỗi. Đổi khoá này sau khi đã dùng sẽ làm mọi khoá API đã lưu không giải mã lại được.
API_KEY_SECRET — nếu thiếu, mọi API key người dùng hỏng sau mỗi lần khởi động lại.

Không dùng nữa — xoá khỏi cấu hình

SUPABASE_URL            SUPABASE_ANON_KEY       SUPABASE_SERVICE_KEY
SUPABASE_JWT_SECRET     SUPABASE_DB_PASSWORD
POSTGRES_DB             POSTGRES_USER           POSTGRES_PASSWORD
GOOGLE_API_KEY

Các biến POSTGRES_* chỉ dùng để khởi tạo container database khi chạy docker compose up ở máy cục bộ. Ứng dụng không đọc chúng.

Lược đồ database tự tạo khi khởi động

Quy trình autodeploy từ git không có terminal, nên bước migration thủ công sẽ không bao giờ chạy được. Ứng dụng vì thế tự dựng lược đồ mỗi lần khởi động:

Nạp database/init.sql — tạo toàn bộ 24 bảng
Nạp scripts/migration_search_fast_final.sql — tạo hàm tìm kiếm search_law()
Kiểm tra lại và ghi kết quả vào log khởi động

Việc này chạy lại nhiều lần vô hại — đối tượng nào đã tồn tại thì bỏ qua. Đặt AUTO_MIGRATE=false nếu muốn tự quản lý bằng scripts/setup_database.py.

Nếu vibehost không có pgvector

init.sql có gọi CREATE EXTENSION vector. Thiếu pgvector thì phần vector được bỏ qua tự động — 3 câu lệnh và 2 cột embedding — phần còn lại cài bình thường.

Điều này không ảnh hưởng tới ứng dụng: tra cứu luật dùng tìm kiếm toàn văn qua search_law(), không cần vector. pgvector chỉ phục vụ script sinh embedding tuỳ chọn.

Đọc /health để chẩn đoán

Trạng thái khi hệ thống khoẻ:

{"status":"ok", "database":"connected", "db_state":"ready",
 "documents":0, "chunks":0, "companies":0}

db_state	Nghĩa là	Cần làm gì
`ready`	Nối được và đủ bảng	Không cần làm gì
`connect_failed`	Không mở được kết nối	Kiểm tra `DB_HOST`, mật khẩu, `DB_SSL_MODE`
`connected_missing_schema`	Nối được nhưng thiếu bảng	Xem log khởi động, kiểm tra `AUTO_MIGRATE`

Cần chi tiết hơn thì bật HEALTH_DETAIL=true để thấy nguyên văn thông báo của driver. Nhớ xoá sau khi chẩn đoán xong — /health là endpoint công khai, thông báo lỗi có kèm tên host.

Log khởi động cũng ghi đích kết nối, không kèm mật khẩu:

Ket noi database: DB_HOST -> <host>:<port>/<dbname> (sslmode=prefer)

Không thấy dòng này nghĩa là vibehost chưa build code mới.

Quy trình deploy

Đẩy code lên HThanh209/Ph-p-l-HR, autodeploy tự kéo về
Kiểm tra /health — cần thấy db_state: ready
Vào /app đăng ký tài khoản đầu tiên (tự động là Chủ sở hữu)
Mật khẩu phải từ 10 ký tự, có chữ HOA, chữ thường, số và ký tự đặc biệt

Rủi ro còn tồn đọng

Chưa xác nhận — file tải lên có thể bị mất

UPLOAD_DIR trỏ tới /app/uploads/documents. Đường dẫn này phải nằm trên ổ đĩa bền vững của vibehost.

Nếu chưa gắn volume, mỗi lần redeploy hoặc khởi động lại sẽ mất sạch hợp đồng team HR đã tải lên. Dữ liệu trong database vẫn còn — chỉ mất file gốc.

Cách kiểm tra: tải lên một file bất kỳ, redeploy, rồi xem file còn không. Làm việc này trước khi giao hệ thống cho team HR dùng thật.

Kho văn bản luật chưa nạp

/health đang báo documents: 0. Nghĩa là rà soát hợp đồng, soạn thảo, so sánh, tóm tắt đều chạy bình thường — nhưng tra cứu luật sẽ không trả về kết quả nào.

Nạp bằng scripts/load_law_data.py và scripts/index_chunks.py. Hai script này cần chạy trên server, mà quy trình autodeploy không có terminal — nếu cần tính năng này thì phải làm nó tự nạp khi khởi động, giống như phần tạo bảng.

Sao lưu database

Toàn bộ hợp đồng, tài liệu, lịch sử trò chuyện và nhật ký đều nằm trong PostgreSQL. Bật sao lưu định kỳ trên vibehost trước khi đưa vào sử dụng chính thức.

Khách tham quan

Dùng thử hệ thống

Tài khoản dùng chung để bạn vào xem Trợ Lý Pháp Lý AI hoạt động thế nào, không cần đăng ký. Đây là tài khoản trải nghiệm nằm trên một không gian riêng biệt, hoàn toàn tách khỏi dữ liệu thật của công ty.

Thông tin đăng nhập

Địa chỉ: CHƯA ĐIỀN — dán link đăng nhập vào đây
Tài khoản: CHƯA ĐIỀN — dán email demo vào đây
Mật khẩu: CHƯA ĐIỀN — dán mật khẩu demo vào đây

Tài khoản dùng chung

Mọi người đăng nhập vào cùng một tài khoản. Nghĩa là tài liệu bạn tải lên, câu hỏi bạn đặt, người dùng thử khác đều xem được. Đừng đưa lên đây hợp đồng thật, thông tin nhân sự thật, hay bất kỳ dữ liệu nào của công ty bạn. Hãy dùng văn bản mẫu.

Giới hạn của tài khoản dùng thử

Hạn mức 100 lượt hỏi mỗi tháng Dùng chung cho tất cả mọi người, nên nếu hệ thống báo hết lượt thì nghĩa là tháng đó đã có nhiều người vào thử. Hạn mức được cấp lại vào đầu tháng.

Chỉ đọc và hỏi, không quản trị Tài khoản ở cấp Thành viên nên tra cứu, soạn thảo và soát văn bản được, nhưng không vào được trang quản trị, không mời người dùng mới, không xem được cấu hình hệ thống.

Dữ liệu có thể bị xoá bất cứ lúc nào Không gian demo được dọn định kỳ. Đừng lưu thứ gì bạn cần giữ lại ở đây — hãy tải kết quả về máy nếu muốn dùng tiếp.

Mật khẩu được đổi định kỳ Nếu đăng nhập báo sai mật khẩu, hãy quay lại trang này xem thông tin mới nhất thay vì thử đi thử lại.

Muốn dùng thật cho công ty?

Tài khoản dùng thử chỉ để xem hệ thống chạy ra sao. Khi triển khai thật, công ty bạn sẽ có không gian riêng: dữ liệu tách biệt, tài khoản riêng cho từng người, phân quyền theo vai trò như mô tả ở mục Cơ chế & Kỹ năng, và hạn mức theo gói đăng ký. Liên hệ quản trị viên hệ thống để được cấp.