Cách nhóm tài chính triển khai ứng dụng do AI xây dựng mà không làm lộ dữ liệu tài chính

Khi công ty bảo mật RedAccess tìm các ứng dụng được tạo bằng công cụ lập trình AI và công bố trên dịch vụ lưu trữ của chính các công cụ đó, họ phát hiện hơn 5.000 ứng dụng gần như không có bảo mật hay xác thực. Những ảnh màn hình gửi cho Wired có “nhiều hồ sơ bán hàng và tài chính từ các công ty khác”. Ứng dụng do AI xây dựng cho nhóm tài chính có thể nằm tại địa chỉ công khai tương tự, với sổ cái, bảng lương và kết quả chưa công bố phía sau.

CEO Replit Amjad Masad trả lời: “Ứng dụng công khai có thể truy cập trên Internet là hành vi như dự kiến”. Ông đúng về cơ chế. Theo tôi, việc lộ dữ liệu bắt nguồn từ thiết lập hiển thị và một lần đánh giá bị bỏ qua, cả hai đều nằm trong khả năng của người xây dựng công cụ.

Tóm tắt nhanh

• Công cụ tài chính do AI xây dựng có thể rò rỉ qua sáu lỗi triển khai mà người tạo có thể xử lý: liên kết công khai, mật khẩu và khóa trong mã hoặc lịch sử trò chuyện, quyền quản trị cơ sở dữ liệu, ghi sổ thiếu người duyệt thứ hai, gửi dữ liệu ra dịch vụ ngoài và thay đổi tính toán không ghi lại.
• Mỗi lỗi có cách sửa, phần lớn bằng chính công cụ AI đã tạo ứng dụng, và kiểm tra cụ thể để chứng minh hiệu quả, như thao tác ghi bị cơ sở dữ liệu từ chối hoặc mật khẩu cũ không còn dùng được.
• Mặc định giữ công cụ trên mạng riêng. Thêm đăng nhập công ty khi người ngoài nhóm tài chính cần truy cập, và giao CNTT nếu công cụ ghi sổ không có người duyệt thứ hai, xử lý dữ liệu thẻ hoặc cung cấp số liệu cho báo cáo tài chính thuộc SOX.
• Khu vực máy chủ quyết định nơi đặt bộ lưu trữ VPS chính của ứng dụng, nhưng bản sao lưu, nhật ký và dịch vụ bên thứ ba có thể tạo bản sao ở nơi khác; việc toàn bộ hệ thống có tuân thủ hay không là một câu hỏi riêng. Hãy mang các khuôn khổ áp dụng cho khu vực của bạn đến trao đổi với nhóm tuân thủ.

Các lỗi triển khai làm rò rỉ dữ liệu tài chính

Công cụ tài chính do AI xây dựng có thể làm rò rỉ dữ liệu qua sáu lỗi triển khai: để công cụ trên liên kết công khai, giữ thông tin đăng nhập trong mã hoặc cuộc trò chuyện, kết nối bằng quyền quản trị trong khi quyền chỉ đọc là đủ, ghi sổ mà không có người duyệt thứ hai, gửi dữ liệu tài chính tới dịch vụ bên ngoài và thay đổi tính toán mà không ghi lại. Mỗi lỗi đều là một thiết lập mặc định mà bản trình diễn khuyến khích.

Mỗi cách sửa dưới đây đi kèm một câu lệnh cho công cụ AI đã xây dựng ứng dụng; hãy sửa các trường trong ngoặc vuông trước khi dán. Các câu lệnh này là điểm khởi đầu chưa được thử nghiệm, viết riêng cho bài này, và việc công cụ AI của bạn báo rằng nó đã thay đổi không chứng minh được điều gì. Bước kiểm tra dưới mỗi câu lệnh mới là bằng chứng. Hãy chạy các câu lệnh trên mã nguồn cùng một bộ dữ liệu mẫu hoặc dữ liệu tổng hợp, và tuyệt đối không dán hồ sơ thật hay khóa đang hoạt động vào cuộc trò chuyện.

Để công cụ trên liên kết công khai của nền tảng xây dựng ứng dụng AI

Bảng dự báo tiền mặt để công khai trên dịch vụ lưu trữ của nền tảng xây dựng ứng dụng AI có thể bị bất kỳ ai có địa chỉ mở ra, cùng mọi thứ hiển thị trên đó: tuổi nợ phải trả, ngân sách so với thực tế, kết quả quý trước khi được công bố. Bài của Wired về phát hiện của RedAccess mô tả cách các nhà nghiên cứu tìm ra những ứng dụng như vậy chỉ bằng các lượt tìm kiếm Google và Bing đơn giản trên tên miền của các nhà cung cấp AI.

Một số ứng dụng trong số đó chỉ yêu cầu người truy cập đăng nhập bằng một địa chỉ email bất kỳ. Trang đăng nhập chấp nhận mọi địa chỉ email thì không phải là kiểm soát truy cập.

Đưa dữ liệu thật ra khỏi dịch vụ lưu trữ nhà cung cấp. Trước khi chạy trên máy chủ bạn kiểm soát, được nói ở phần tiếp theo, hãy xây dựng và trình diễn bằng dữ liệu tổng hợp hoặc sandbox hay công ty thử nghiệm của ERP nếu có, không dùng bản xuất thật. Triển khai lại sau khi sửa vì địa chỉ lưu trữ phục vụ phiên bản được triển khai gần nhất.

Tạo một bộ dữ liệu tổng hợp cho ứng dụng này, khớp với các bảng và cột mà ứng dụng đọc: [liệt kê bảng và cột, ví dụ vendors, invoices, journal_lines].

Dùng tên nhà cung cấp, khách hàng và tài khoản ngân hàng giả, với số tiền bằng [tiền tệ] có logic như sổ thật: mỗi bút toán cân đối và tổng sổ phụ khớp với [tài khoản kiểm soát phải trả / phải thu].

Chuyển ứng dụng sang dữ liệu này thay vì bản xuất thật, và liệt kê mọi tệp hoặc thiết lập đã sửa.

Không yêu cầu tôi cung cấp hồ sơ thật.

Xác nhận hiệu quả: mở địa chỉ do nhà cung cấp lưu trữ bằng trình duyệt chưa đăng nhập, hoặc nhờ một đồng nghiệp ngoài bộ phận tài chính làm việc này, và xác nhận rằng trang chỉ hiển thị dữ liệu tổng hợp, màn hình yêu cầu đăng nhập hoặc không hiển thị gì cả. Sau đó tìm trong các tệp dữ liệu của ứng dụng và kho mã ba tên nhà cung cấp hoặc khách hàng lấy từ ERP thật của bạn; không được có kết quả nào. Cuối cùng, chạy bảng cân đối thử hoặc màn hình tổng hợp của ứng dụng và xác nhận tổng Nợ bằng tổng Có.

Để thông tin đăng nhập ERP, dữ liệu ngân hàng và cơ sở dữ liệu trong mã hoặc trò chuyện

Nếu thông tin đăng nhập đang hoạt động được lưu ở đó, bất kỳ ai đọc được lịch sử trò chuyện, kho mã hoặc tệp cấu hình MCP cũng có thể dùng nó để truy cập ERP, cơ sở dữ liệu tài chính hoặc tích hợp nguồn dữ liệu ngân hàng. MCP là bộ kết nối cho phép công cụ AI như Claude giao tiếp trực tiếp với ERP hoặc cơ sở dữ liệu, và tệp cấu hình của nó là thêm một nơi có thể chứa mật khẩu.

State of Secrets Sprawl 2026 của GitGuardian tìm thấy 24.008 bí mật riêng biệt bị lộ trong cấu hình MCP, 14% là chuỗi kết nối PostgreSQL. Trong commit GitHub công khai, báo cáo cũng thấy commit do Claude Code đồng tác giả rò rỉ bí mật với tỷ lệ khoảng gấp đôi nền chung, đồng thời nhấn mạnh yếu tố con người vẫn quan trọng.

Xóa tin nhắn trò chuyện không đảo ngược được việc lộ dữ liệu: ai có bản sao cuộc trò chuyện, kho mã hoặc lịch sử của kho mã vẫn giữ giá trị đó. Với mỗi mật khẩu, khóa hoặc token từng nằm ở một trong những nơi đó, hãy cấp cái mới trong bảng quản trị của ERP, cơ sở dữ liệu hoặc nguồn dữ liệu ngân hàng rồi vô hiệu hóa cái cũ. Đó chính là luân chuyển thông tin xác thực.

Sau đó, ứng dụng đọc thông tin xác thực khi khởi động từ biến môi trường (các thiết lập có tên được giữ bên ngoài mã), do lớp triển khai cung cấp, tức công cụ xây dựng và chạy ứng dụng trên máy chủ của bạn. HashiCorp Vault là bước nâng cấp khi nhiều công cụ dùng chung bí mật và cần luân chuyển chúng từ một nơi.

Bản sao mật khẩu của chính nhóm nên nằm trong một trình quản lý mật khẩu dành cho con người, như Vaultwarden; ứng dụng đang chạy thì đọc giá trị từ biến môi trường. Hãy bắt đầu bằng việc tìm mọi bí mật được ghi trực tiếp trong mã do AI tạo ra.

Kiểm tra dự án này để tìm bí mật được ghi trực tiếp trong mã. Tìm mọi mật khẩu, khóa API, token truy cập và chuỗi kết nối, kể cả trong tệp .env, notebook, tệp cấu hình MCP và đoạn mã kết nối tới [tên ERP / nhà cung cấp dữ liệu ngân hàng / cơ sở dữ liệu tài chính].

Thay từng giá trị trong mã bằng một biến môi trường có tên, rồi đưa cho tôi danh sách tên các biến.

Đảm bảo không có tệp nào chứa giá trị thật được commit vào kho mã, và liệt kê mọi commit trong lịch sử kho mã có xuất hiện một trong các giá trị này.

Chỉ cho tôi xem vị trí. Không in ra bất kỳ giá trị bí mật nào.

Xác nhận hiệu quả: tự thử mật khẩu hoặc token cũ, hoặc nhờ CNTT thử, và nó phải bị từ chối. Sau đó tìm các giá trị cũ trong tệp hiện tại của dự án; không được có kết quả nào. Một giá trị còn sót lại trong lịch sử chỉ thực sự không còn cấp quyền truy cập sau khi bạn đã xác nhận giá trị đó đã bị thu hồi hoặc hết hạn.

Dùng đăng nhập quản trị của người tạo khi công cụ chỉ cần đọc

Bảng điều khiển hiển thị tuổi nợ phải thu không được có khả năng sửa sổ cái. Nếu công cụ kết nối bằng đăng nhập quản trị của người tạo, nó kế thừa quyền của tài khoản đó. Khóa bí mật Supabase, hoặc khóa cũ service_role, cấp quyền truy cập nâng cao vào dữ liệu của dự án và bỏ qua Row Level Security, vì vậy không nên dùng nó cho truy cập chỉ đọc thông thường. Khi đó, một báo cáo được xây dựng cho một lịch tuổi nợ sẽ làm lộ toàn bộ sổ cái, kể cả các bảng lương.

Khả năng ghi khiến hậu quả tốn kém. Khảo sát 1.072 ứng dụng do AI xây dựng của Symbiotic Security dùng Supabase phát hiện 172 ứng dụng cho phép bất kỳ ai xóa bản ghi mà không cần xác thực, 172 ứng dụng cho phép bất kỳ ai sửa bản ghi hiện có và 39 ứng dụng có bảng mà bất kỳ người nào giữ khóa công khai cũng có thể đọc toàn bộ.

Cấp cho công cụ thông tin xác thực chỉ đọc, giới hạn ở các bảng mà nó đọc. Trong ERP hoặc cơ sở dữ liệu, điều đó có nghĩa là một người dùng tích hợp chuyên biệt: một tài khoản riêng được tạo cho công cụ, chỉ có quyền đọc các đối tượng mà báo cáo cần và không gì khác. Trên Supabase, hãy bật Row Level Security (quy tắc cơ sở dữ liệu quyết định mỗi yêu cầu được thấy những hàng nào) cho mọi bảng được mở truy cập mà công cụ sử dụng, đồng thời rà soát cả quyền cấp trên bảng: các quyền này quyết định một vai trò có được select, insert, update hay delete hay không. Với một ứng dụng tài chính chỉ đọc, vai trò mà nó dùng không nên có các thao tác ghi không cần thiết. Khóa publishable có thể nằm trong mã trình duyệt khi RLS và quyền tối thiểu được thiết lập đúng. Khóa bí mật và khóa cũ service_role phải ở phía máy chủ, và chỉ nên dành cho các tác vụ backend thực sự cần quyền nâng cao và tự thực thi việc kiểm tra ủy quyền của riêng chúng.

Lưu ý: khóa publishable của Supabase, hoặc khóa cũ anon, hiển thị trong JavaScript của trang là bình thường. Tài liệu khóa API của Supabase cho biết khóa này chỉ truy cập được những gì Row Level Security cho phép. Khóa bí mật bỏ qua Row Level Security, nên tuyệt đối không được xuất hiện trong bất kỳ nội dung nào gửi tới trình duyệt.

Liệt kê mọi đọc và ghi của ứng dụng tới [tên ERP hoặc cơ sở dữ liệu], theo bảng hoặc đối tượng.

Sửa ứng dụng để nó chỉ đọc [bảng cần thiết] và kết nối bằng một thông tin xác thực chỉ đọc riêng, được cung cấp qua biến môi trường, không bao giờ dùng đăng nhập của tôi.

Nếu ứng dụng dùng Supabase: bật Row Level Security cho mọi bảng được mở truy cập mà ứng dụng tác động tới. Liệt kê các quyền select, insert, update và delete của anon và authenticated. Với ứng dụng chỉ đọc này, hãy bỏ các quyền ghi không cần thiết; nếu một ứng dụng đang chạy thực tế khác phụ thuộc vào một quyền nào đó, hãy đánh dấu quyền đó thay vì thay đổi nó. Sau đó viết chính sách để người truy cập chưa đăng nhập không đọc được gì và người dùng đã đăng nhập chỉ đọc được [quy tắc, ví dụ hàng của trung tâm chi phí của họ], và xác nhận không có khóa bí mật hoặc khóa cũ service_role nào xuất hiện trong bất kỳ tệp nào gửi tới trình duyệt.

Liệt kê chính sách đã tạo.

Xác nhận hiệu quả: dùng thông tin xác thực của công cụ để thử một thao tác ghi, chẳng hạn sửa một bản ghi thử, và thao tác đó phải bị từ chối. Với Supabase, yêu cầu các hàng của một bảng tài chính khi chưa đăng nhập; kết quả phải rỗng hoặc báo lỗi.

Cho công cụ ghi sổ mà không có người duyệt thứ hai

Bộ nhập bút toán ghi trực tiếp hoặc bộ tạo tệp thanh toán gửi thẳng ngân hàng khiến người chạy vừa lập vừa duyệt. Một lỗi có thể ghi trùng cả tháng bút toán dồn tích. Một trường bị sửa có thể gửi tiền nhà cung cấp đến sai tài khoản. Tài chính không cho phép vi phạm phân tách nhiệm vụ giữa hai người, và phần mềm tạo bằng trợ lý AI cũng không được miễn.

Thiệt hại không dừng lại trong ứng dụng. Một lô sai sẽ đi vào sổ sách, nơi việc hoàn tác cần một bút toán điều chỉnh và lời giải thích khi khóa sổ, và khi công cụ ghi sổ bằng đăng nhập cá nhân của người tạo, mọi bút toán trùng lặp đều mang tên người đó.

Công cụ do AI xây dựng đọc và chuẩn bị; việc ghi sổ và giải phóng thanh toán diễn ra trong quy trình phê duyệt riêng của ERP, do một người khác với người đã chạy công cụ phê duyệt. Mọi bộ máy kế toán tôi từng làm đều coi bút toán và việc phê duyệt nó là hai sự kiện với hai người chịu trách nhiệm, và một công cụ do AI xây dựng cũng xứng đáng được đối xử như vậy.

Trên thực tế, hãy chuyển mỗi thao tác ghi trực tiếp thành một bút toán nháp hoặc một bản nhập chuẩn bị chờ phê duyệt bên trong ERP. Công cụ vẫn làm phần việc tẻ nhạt (ánh xạ, kiểm tra hợp lệ, tạo lô), còn việc phê duyệt vẫn nằm trong ERP, bên cạnh mọi phê duyệt khác mà quá trình khóa sổ phụ thuộc vào. Nếu ERP không có bước phê duyệt cho bản nhập, đầu ra của công cụ sẽ là một tệp để người thứ hai đối chiếu với bản tổng hợp lô và tự nhập vào.

Công cụ buộc phải ghi sổ tự động, tạo tệp thanh toán hoặc thay đổi thông tin tài khoản ngân hàng của nhà cung cấp thì thuộc về CNTT, theo các điều kiện ở phần tiếp theo.

Liệt kê mọi nơi ứng dụng này tạo, sửa hoặc ghi [bút toán / hóa đơn / thanh toán] trong [tên ERP].

Sửa từng nơi để ứng dụng tạo một bút toán nháp hoặc một bản nhập chuẩn bị phải được phê duyệt trong [tên ERP] trước khi được ghi sổ. Nếu [tên ERP] không có bước phê duyệt cho bản nhập, hãy tạo một tệp nhập thay thế và không ghi sổ gì cả.

Xóa mọi nhánh mã ghi sổ hoặc giải phóng thanh toán mà không có phê duyệt đó.

Với mỗi lô, tạo một bản tổng hợp gồm số hàng, tổng Nợ và tổng Có.

Liệt kê mọi thứ vẫn còn ghi sổ trực tiếp để tôi xem xét.

Xác nhận hiệu quả: chạy một lô từ dữ liệu mẫu. Không có gì được hiển thị là đã ghi sổ cho đến khi người dùng thứ hai phê duyệt lô đó trong ERP. Sau đó so sánh bản tổng hợp lô với những gì ERP hiển thị cho lô đó: số hàng, tổng Nợ và tổng Có phải khớp hoàn toàn. Chênh lệch một hàng là đối chiếu thất bại, không phải vấn đề làm tròn.

Gửi dữ liệu tài chính tới dịch vụ ngoài tầm kiểm soát

Tính năng bình luận chênh lệch gửi toàn bộ bản trích xuất sổ cái tới API AI sẽ chuyển từng dòng cho bên thứ ba. Còn hai con đường kín đáo hơn đưa dữ liệu ra ngoài: mã phân tích trên trang, vốn báo cáo từng lượt truy cập cho nhà cung cấp của nó, và công cụ theo dõi lỗi hoặc nhật ký lưu toàn bộ nội dung yêu cầu, nơi các dòng lương, thông tin tài khoản ngân hàng của khách hàng và số liệu chưa công bố có thể xuất hiện.

Với công cụ nội bộ do bộ phận tài chính xây dựng, không đưa kết quả chưa công bố và bảng lương vào các lệnh gọi tới bên thứ ba, trừ khi dịch vụ đó và luồng dữ liệu cụ thể đã được phê duyệt rõ ràng qua quy trình nhà cung cấp, bảo mật và tuân thủ của tổ chức bạn. Với mọi dữ liệu khác, hãy liệt kê mọi điểm đến và chỉ gửi cho mỗi lệnh gọi những trường nó cần. Việc dịch vụ bên ngoài có lưu trữ hoặc dùng dữ liệu nhận được để huấn luyện hay không là câu hỏi dành cho người ký hợp đồng với nhà cung cấp, được kiểm tra theo chính điều khoản của nhà cung cấp đó. Nếu nhóm muốn biết công cụ được dùng thường xuyên đến mức nào, công cụ phân tích tự lưu trữ như Umami sẽ giữ các lượt xem trang đó trên máy chủ của chính bạn.

Liệt kê mọi nơi ứng dụng này gửi dữ liệu ra ngoài [máy chủ của chúng ta], bao gồm API AI, mã phân tích, công cụ theo dõi lỗi, email, webhook và tệp nhật ký.

Với mỗi điểm đến, liệt kê chính xác những trường mà nó nhận.

Đánh dấu mọi thứ chứa [tiền lương / số tài khoản ngân hàng / kết quả chưa công bố / tên khách hàng].

Với mỗi mục được đánh dấu, chỉ ra cách gửi ít trường hơn hoặc không gửi gì, và chỉ thực hiện thay đổi sau khi tôi xác nhận.

Xác nhận hiệu quả: kích hoạt mỗi tính năng một lần với dữ liệu mẫu chứa một số tài khoản giả dễ nhận biết và một khoản lương giả. Tìm cả hai giá trị trong công cụ theo dõi lỗi và nhật ký; không được có kết quả nào. Với đường gửi tới API AI, cho ứng dụng ghi lại nội dung yêu cầu gửi đi trong lần chạy mẫu đó, tìm hai giá trị này trong nhật ký; không được thấy giá trị nào, và chỉ có các trường bạn đã phê duyệt. Tắt việc ghi nhật ký này sau đó.

Thay đổi tính toán không ghi lại và không đối chiếu

Trong bộ tính bút toán dồn tích hoặc công cụ kiểm tra waterfall doanh thu, mã chính là kiểm soát. Thay đổi một công thức thì số liệu đi vào kỳ khóa sổ cũng thay đổi theo, và nếu không có quản lý phiên bản, không ai có thể biết ai đã thay đổi gì, hay vào lúc nào.

Trong chủ đề r/ClaudeAI của một hãng CPA về các công cụ nội bộ mà hãng xây dựng bằng Claude Code, một người bình luận nêu thẳng giới hạn: “‘kế toán + claude code’ dùng được tới khi gặp yêu cầu dấu vết kiểm toán. Đó là trần thực sự.”

Cố định hành vi hiện tại trước khi thay đổi bất cứ điều gì; khi đầu ra đã được cố định, logic có thể được cải thiện mà các tổng số không âm thầm bị lệch. Lưu mã trong hệ thống quản lý phiên bản, nơi ghi lại mọi thay đổi cùng tác giả và ngày thực hiện.

Viết kiểm thử chạy công cụ trên một tệp mẫu cố định và so sánh kết quả với một mốc đã ghi lại, để mã phải vượt qua bước đối chiếu trước khi bất kỳ thay đổi nào được phát hành. Kiểm thử đã cố định sẽ bảo vệ mọi thứ nó ghi lại, kể cả lỗi, vì vậy hãy đối chiếu tổng của mốc với tổng của ERP cho cùng kỳ trước khi tin vào chúng.

Yêu cầu một người thứ hai xem xét mọi thay đổi đối với logic tính toán, và đối chiếu mỗi lần chạy thực tế với chính tổng số của ERP.

Đưa dự án này vào quản lý phiên bản nếu chưa có, và liệt kê những tệp chứa logic tính toán.

Viết kiểm thử chạy ứng dụng trên [tệp mẫu] và ghi lại đầu ra hiện tại: số hàng và tổng theo [tài khoản / đơn vị / kỳ].

Trước khi lưu đầu ra đã ghi lại, cho tôi xem các tổng để tôi đối chiếu với [tên ERP] cho [kỳ].

Mọi thay đổi làm thay đổi một trong các tổng đó đều phải khiến một kiểm thử thất bại.

Không sửa logic tính toán khi viết kiểm thử.

Xác nhận hiệu quả: cố ý thay đổi một phép tính, ví dụ một quy tắc làm tròn, và xác nhận rằng một kiểm thử thất bại. Hoàn tác thay đổi và xác nhận mọi kiểm thử lại đạt.

Mặc định riêng tư, đăng nhập công ty khi nhiều người cần dùng hơn, CNTT cho sổ cái

Dữ liệu tài chính thật không bao giờ được để lại trên dịch vụ lưu trữ của công cụ AI. Để triển khai an toàn một ứng dụng tài chính do AI xây dựng chỉ dành cho nhóm tài chính, hãy đặt nó trên máy chủ bạn kiểm soát, chỉ truy cập được qua mạng riêng. Thêm đăng nhập công ty khi người ngoài nhóm cần dùng, và giao cho CNTT khi bất kỳ điều kiện nào trong danh sách bên dưới là đúng.

VPS là máy chủ ảo đi thuê, trong đó bạn kiểm soát hệ điều hành và toàn bộ phần mềm. Mạng riêng (theo cách gọi của Tailscale là tailnet) kết nối các thiết bị được phê duyệt với máy chủ đó. Để công cụ không lộ ra Internet công khai, bạn vẫn phải chặn truy cập công khai từ bên ngoài vào ứng dụng, chẳng hạn bằng tường lửa của máy chủ, và chỉ mở ứng dụng qua giao diện VPN hoặc tailnet. Nhà cung cấp danh tính lưu giữ tài khoản người dùng của công ty, còn reverse proxy là người gác cổng đứng trước ứng dụng, buộc mọi yêu cầu phải qua bước đăng nhập trước.

Dịch vụ lưu trữ của chính công cụ AI không có trong bảng vì những lý do nêu ở lỗi đầu tiên. Nền tảng triển khai doanh nghiệp như Northflank cũng vậy: nó phù hợp với các tổ chức lớn hơn vốn đã có ngân sách cho nhà cung cấp nền tảng và các quy trình đánh giá mà họ yêu cầu. Mức hợp đồng đó vượt quá nhu cầu của một công cụ cấp phòng ban chỉ có vài người dùng.

Theo kinh nghiệm của tôi, Tailscale là lựa chọn nhanh hơn để triển khai trong hai phương án mạng riêng, nhưng Tailscale tự lưu trữ dịch vụ điều phối. WireGuard là lựa chọn hoàn toàn tự lưu trữ.

Lý do tôi chọn mạng riêng làm mặc định: một công cụ không phản hồi từ Internet thì không thể bị tìm thấy qua tìm kiếm hay bị tấn công ở trang đăng nhập, trong khi trang đăng nhập do công cụ AI viết chỉ tốt bằng đoạn mã do AI viết phía sau nó. Nếu cần mở ứng dụng ra ngoài mạng riêng, đăng nhập công ty sẽ thêm một lớp xác thực được quản lý ở phía trước, và đó là lý do nó đứng thứ hai.

Khi chủ ngân sách cần truy cập, hãy thay trang đăng nhập riêng của công cụ bằng đăng nhập công ty, còn gọi là single sign-on (SSO): mọi người dùng tài khoản công ty sẵn có, nên vô hiệu hóa tài khoản đó sẽ chặn các lần đăng nhập mới; hãy cấu hình thu hồi phiên, back-channel logout hoặc thời hạn phiên đủ ngắn để các phiên hiện có không tồn tại lâu. Câu lệnh dùng OIDC, một giao thức đăng nhập chuẩn mà cả Authentik và Keycloak đều hỗ trợ.

Thay trang đăng nhập riêng của ứng dụng này bằng đăng nhập công ty qua [Authentik / Keycloak / nhà cung cấp danh tính của chúng ta] dùng OIDC.

Đọc nhóm của từng người dùng từ thông tin đăng nhập.

Chỉ cho phép thành viên của [tên nhóm] truy cập [trang bảng lương], và thực thi quy tắc đó trên máy chủ cho mọi trang, mọi bản xuất và mọi endpoint API, không chỉ trong menu.

Từ chối mọi yêu cầu không kèm theo đăng nhập hợp lệ.

Xác nhận hiệu quả: đăng nhập bằng một tài khoản thử không thuộc nhóm, yêu cầu trực tiếp trang bị hạn chế cùng địa chỉ bản xuất hoặc API của trang đó; cả hai đều phải bị từ chối. Sau đó vô hiệu hóa tài khoản thử trong nhà cung cấp danh tính và xác nhận tài khoản đó không thể bắt đầu phiên mới. Đồng thời xác nhận phiên hiện có bị thu hồi hoặc hết hạn trong khoảng thời gian bạn đã cấu hình.

Một số công cụ hoàn toàn không nên ở lại với nhóm. Hãy giao công cụ cho CNTT hoặc bộ phận kỹ thuật khi bất kỳ điều kiện nào sau đây là đúng:

1. Ghi vào sổ cái hoặc hệ thống hồ sơ chính thức khác không có người duyệt trong ERP.
2. Tạo tệp thanh toán, giải phóng thanh toán hoặc thay đổi thông tin tài khoản ngân hàng của nhà cung cấp.
3. Đầu ra của công cụ được đưa vào báo cáo tài chính của một đơn vị đăng ký với SEC, điều này có thể đưa công cụ vào phạm vi kiểm soát nội bộ đối với báo cáo tài chính (ICFR). Hãy trao đổi với kiểm toán nội bộ trước khi dùng công cụ trong kỳ khóa sổ; với các tổ chức phát hành thuộc diện áp dụng SOX Section 404(b), kiểm toán viên độc lập cũng có thể kiểm tra các kiểm soát liên quan.
4. Lưu, xử lý hoặc truyền dữ liệu thẻ thanh toán.
5. Đánh giá khả năng tín dụng cá nhân.
6. Không ai trong nhóm nhận trách nhiệm vá lỗi, đánh giá quyền truy cập và ngừng sử dụng công cụ.

Điều kiện thứ sáu quan trọng hơn vẻ ngoài. Tự lưu trữ nghĩa là bạn chịu trách nhiệm cập nhật, sao lưu và giám sát, và một công cụ tài chính không ai bảo trì sẽ an toàn hơn khi ở với CNTT. CNTT có thể chậm hơn; đó là cái giá của việc quản trị mà các điều kiện này đòi hỏi.

Với cấp 1 và 2, máy chủ, lớp triển khai, mạng riêng và, với cấp 2, nhà cung cấp danh tính đều phải sẵn sàng trước khi bất kỳ ai mở công cụ, và một nhóm tài chính không có kỹ sư phải tự dựng toàn bộ những thứ đó. Trên Linux VPS của chúng tôi, bạn có quyền root. Coolify và WireGuard có sẵn dưới dạng triển khai một nhấp chuột; Tailscale được cài bằng trình cài đặt chính thức chỉ với một lệnh, còn Authentik chạy từ stack Docker Compose chính thức. Nhờ vậy, thời gian của nhóm có thể dành cho các cách sửa ở trên thay vì dựng stack triển khai từ đầu. Các vị trí của chúng tôi gồm Frankfurt và Amsterdam ở EU, London ở Anh và nhiều thành phố tại Mỹ, cho phép bạn chọn khu vực đặt bộ lưu trữ VPS chính của ứng dụng; việc lựa chọn đó có chấp nhận được hay không vẫn do bộ phận tuân thủ quyết định.

Quy định cần kiểm tra với nhóm tuân thủ theo khu vực

Khuôn khổ nào áp dụng phụ thuộc vào dữ liệu mà công cụ tiếp cận, cũng như vị trí của công ty và của những người có trong dữ liệu. Một bảng lương chứa mức lương của nhân viên EU và một lịch doanh thu đưa vào báo cáo tài chính của một công ty niêm yết tại Mỹ có thể thuộc các khuôn khổ khác nhau.

Không nội dung nào trong bài viết này là tư vấn pháp lý. Bảng dưới đây liệt kê các khuôn khổ để bạn trao đổi với nhóm tuân thủ, và không quyết định khuôn khổ nào áp dụng cho bạn.

Với hàng SOX, AS 2201 là chuẩn mực của PCAOB cho việc xác nhận của kiểm toán viên mà Section 404(b) của Đạo luật Sarbanes-Oxley đề cập, và chuẩn mực này nêu các kiểm soát đối với bút toán và điều chỉnh được thực hiện trong quy trình lập báo cáo tài chính cuối kỳ là một trong những kiểm soát mà kiểm toán viên đánh giá khi xử lý rủi ro gian lận. Ngoài các khu vực này, hãy bắt đầu từ trang web của chính cơ quan quản lý bảo vệ dữ liệu quốc gia của bạn. Vị trí của máy chủ quyết định nơi đặt bộ lưu trữ chính; nó không cho bạn biết mọi bản sao lưu, nhật ký hay bản sao của bên thứ ba nằm ở đâu, và tự nó không đáp ứng bất kỳ khuôn khổ nào ở trên.

Câu hỏi thường gặp

Vibe coding có an toàn cho công cụ tài chính không?

Có thể an toàn sau khi khắc phục các khoảng trống mà bản trình diễn để lại; theo tôi, bằng chứng cho thấy đây là vấn đề triển khai nhiều hơn là vấn đề lập trình. Công cụ tài chính rủi ro hơn dự án cá nhân vì nó đọc ERP và có thể ghi vào sổ kế toán. Khi công cụ ghi sổ không có người duyệt thứ hai, xử lý thanh toán hoặc dữ liệu thẻ, cần giao cho CNTT.

Shadow AI trong tài chính là gì?

Shadow AI là các công cụ AI hoặc ứng dụng do AI xây dựng được dùng trên dữ liệu công ty mà CNTT không biết hoặc không phê duyệt, chẳng hạn một bảng dự báo kết nối với ERP mà CNTT chưa từng thấy. Theo thông báo của IBM, Cost of a Data Breach Report 2025 của IBM cho thấy các tổ chức có mức độ shadow AI cao có chi phí rò rỉ dữ liệu trung bình cao hơn 670.000 USD so với các tổ chức có mức độ thấp hoặc không có.

Nên trình gì cho kiểm toán nội bộ hoặc kiểm toán viên bên ngoài?

Hãy chuẩn bị bốn thứ trước khi công cụ được dùng trong kỳ khóa sổ: công cụ chạy ở đâu và ai có thể truy cập, lịch sử thay đổi cùng các kiểm thử đầu ra cố định, cách các bút toán được phê duyệt trong ERP, và bằng chứng đối chiếu khớp từng lô với tổng số của ERP. Kiểm toán viên yêu cầu gì là quyền quyết định của họ; bốn thứ này cho họ cơ sở cụ thể để đánh giá.

Ai chịu trách nhiệm về công cụ tài chính do AI xây dựng sau khi người tạo rời đi?

Chỉ định một người phụ trách trong bộ phận tài chính và một đầu mối kỹ thuật trước khi ra mắt. Chạy công cụ bằng thông tin xác thực dịch vụ thay vì đăng nhập riêng của người tạo, và cho mọi truy cập đi qua đăng nhập công ty để việc vô hiệu hóa tài khoản công ty của người nghỉ việc sẽ chặn các lần đăng nhập mới, còn các phiên hiện có bị thu hồi hoặc được để hết hạn theo chính sách phiên của bạn. Ngừng sử dụng công cụ nghĩa là vô hiệu hóa thông tin xác thực của nó, giữ lại những gì chính sách lưu giữ của bạn yêu cầu, xóa phần còn lại và tắt công cụ.