Bài viết

Có, nhưng câu trả lời đáng tin hơn là: AI phân tích tài chính chỉ hiệu quả khi ta xác định đúng phần việc cần giao cho máy, phần việc bắt buộc người giữ quyền kiểm soát, và cách kiểm tra đầu ra trước khi nó đi vào quyết định thật.
Nhiều người hỏi câu này với một kỳ vọng hơi nguy hiểm: đưa báo cáo tài chính, file Excel, tin tức thị trường vào một chatbot rồi nhận về khuyến nghị mua, bán, đầu tư hay cắt giảm chi phí. Cách làm đó có thể cho ra một bản phân tích nghe rất trơn tru. Vấn đề là sự trơn tru của câu chữ không phải bằng chứng cho chất lượng của kết luận.
Tôi nghĩ AI hữu ích nhất trong tài chính khi được xem như một lớp tăng năng suất cho người phân tích: đọc nhanh hơn, nhóm thông tin nhanh hơn, phát hiện điểm cần hỏi nhanh hơn, dựng bản nháp nhanh hơn. Nếu xem nó là người chịu trách nhiệm cuối cùng cho một quyết định liên quan đến tiền, rủi ro, pháp lý hay danh tiếng, ta đang đẩy quá nhiều niềm tin vào một hệ thống vốn có thể trả lời sai mà vẫn rất tự tin.
Đây là điểm cần nói thẳng: AI không tự hiểu doanh nghiệp của bạn. Nó không tự biết một khoản chi phí tăng là tín hiệu xấu, là đầu tư cần thiết, là hạch toán dồn tích hay chỉ là dữ liệu nhập nhầm. Nó chỉ có thể xử lý tín hiệu mà bạn đưa vào, theo cấu trúc, chỉ dẫn và công cụ mà bạn cho phép dùng.
Cụm từ này quá rộng nên dễ dẫn đến kỳ vọng sai. Có người cần AI đọc báo cáo kết quả kinh doanh. Có người muốn so sánh ngân sách với thực tế. Có người cần rà soát hóa đơn, phân loại giao dịch, tóm tắt biến động dòng tiền hoặc chuẩn bị câu hỏi cho buổi họp với ban điều hành. Có người lại muốn dự báo doanh thu.
Những bài toán đó khác nhau về dữ liệu, mức rủi ro và tiêu chuẩn kiểm tra. Một hệ thống giúp nhân viên tài chính tìm nhanh các giao dịch có mô tả bất thường là một chuyện. Một hệ thống đưa ra kết luận về khả năng thanh toán hay khuyến nghị phân bổ vốn là chuyện khác hẳn.
Tôi thường tách công việc thành ba lớp.
AI làm khá tốt ở lớp đầu nếu dữ liệu sạch và quyền truy cập được kiểm soát. Ở lớp thứ hai, AI có giá trị khi nó gọi được công cụ tính toán hoặc truy vấn trực tiếp vào nguồn dữ liệu chuẩn, thay vì tự nhẩm rồi viết ra đáp án. Lớp thứ ba vẫn cần người hiểu doanh nghiệp, hiểu bối cảnh giao dịch và chịu trách nhiệm khi quyết định sai.
Điểm mấu chốt là đừng đánh giá AI qua một màn demo. Hãy đánh giá nó qua một Workflow thật: ai dùng, dùng dữ liệu nào, đầu ra đi đâu, ai kiểm, lỗi xảy ra thì phát hiện thế nào, và có thể lần lại nguyên nhân hay không.
Đừng bắt đầu bằng câu hỏi “AI có thay người phân tích không?”. Hãy bắt đầu bằng câu hỏi thực dụng hơn: “Đội của tôi đang mất thời gian ở đâu mà giá trị suy luận tạo ra không tương xứng?”
Một ví dụ dễ thấy là đọc tài liệu. Đội tài chính thường phải xử lý hợp đồng, hóa đơn, email, thuyết minh báo cáo, tài liệu ngân sách, biên bản họp và các file có cấu trúc rất lộn xộn. AI có thể giúp tạo bản tóm tắt theo mẫu: nghĩa vụ thanh toán, thời hạn, điều khoản cần chú ý, các khoản phải xác nhận. Đầu ra đó chưa phải sự thật cuối cùng, nhưng nó là một bản nháp tốt để người phụ trách bắt đầu kiểm tra.
Việc tiếp theo là giải thích biến động. Khi doanh thu, chi phí hoặc công nợ đổi so với kỳ trước, AI có thể hỗ trợ gom nhóm các khoản biến động, sắp xếp theo mức độ liên quan và viết một bản diễn giải ban đầu. Người phân tích sau đó đối chiếu với nguồn gốc: dữ liệu bán hàng, chính sách giá, hợp đồng, hoạt động vận hành hay thay đổi cách ghi nhận.
Ở đây, giá trị của AI không nằm ở đoạn văn “hay”. Giá trị nằm ở việc nó khiến người làm tài chính không phải nhìn một bảng dài rồi tự bắt đầu từ số không. Nó gợi ý nơi cần đào sâu. Đó là khác biệt lớn.
Một việc khác phù hợp là hỗ trợ hỏi đáp trên kho tài liệu nội bộ. Ví dụ, nhân viên cần biết quy định chi phí công tác, cách phân loại một khoản chi, hay quy trình phê duyệt thanh toán. Nếu tài liệu đã được quản trị tốt, một hệ thống RAG có thể trả lời kèm nguồn tham chiếu. Nếu bạn đang cân nhắc làm kiểu này, bài viết về RAG từ Zero đến Production có một khung tư duy hữu ích: câu trả lời đáng dùng phải bám dữ liệu gốc, chứ không phải bám trí nhớ mơ hồ của mô hình.
AI cũng hữu ích trong việc chuẩn bị cho các cuộc họp. Nó có thể biến một tập số liệu và ghi chú thành danh sách câu hỏi: khoản nào có biến động chưa được giải thích, giả định nào cần xác nhận, số nào mâu thuẫn giữa hai báo cáo. Tôi thích dùng AI theo hướng này hơn là bắt nó “kết luận hộ” tôi. Một danh sách câu hỏi tốt thường tạo ra cuộc họp tốt hơn một bản kết luận có vẻ hoàn chỉnh nhưng không ai biết nó dựa vào đâu.
Phân tích tài chính luôn có một cám dỗ: thấy vài con số cùng thay đổi rồi lập tức gán nguyên nhân. AI đặc biệt giỏi viết ra kiểu giải thích đó. Nó có thể nối doanh thu, chi phí, thị trường, hành vi khách hàng và chiến lược thành một câu chuyện nghe rất thuyết phục.
Nhưng một câu chuyện thuyết phục chưa chắc là một kết luận đúng.
Nếu nguồn dữ liệu sai, bị thiếu, khác kỳ ghi nhận, trùng giao dịch, lệch đơn vị tiền tệ hoặc dùng định nghĩa chỉ tiêu khác nhau, AI vẫn sẽ cố trả lời. Nhiều người mới dùng đánh giá cao việc mô hình không bỏ trống câu hỏi. Tôi thì xem đây là một điểm cần cảnh giác. Trong tài chính, đôi khi câu trả lời đúng nhất là: “Dữ liệu hiện tại chưa đủ để kết luận.”
Một AI tài chính đáng tin không phải hệ thống trả lời mọi câu hỏi. Nó là hệ thống biết chỉ ra dữ liệu nào đang thiếu, giả định nào đang được dùng và chỗ nào cần người xác nhận.
Vì vậy, đừng đưa một file Excel vào chatbot rồi hỏi “hãy phân tích tình hình tài chính”. Câu hỏi quá rộng sẽ sinh ra câu trả lời rộng, nhiều nhận định chung và rất khó kiểm tra. Hãy tách yêu cầu thành phần nhỏ: xác định bảng nào là nguồn chuẩn, nêu công thức, chỉ rõ kỳ so sánh, yêu cầu trích dẫn dòng dữ liệu liên quan, và buộc hệ thống nêu các giả định.
Ví dụ, thay vì hỏi “chi phí tăng vì sao?”, hãy yêu cầu: liệt kê các nhóm chi phí có chênh lệch; hiển thị giá trị nguồn cho từng nhóm; đánh dấu khoản chưa có mô tả; không suy đoán nguyên nhân nếu thiếu bằng chứng. Câu prompt này nghe bớt hào nhoáng, nhưng phù hợp với công việc tài chính hơn nhiều.
Một sai lầm kỹ thuật phổ biến là yêu cầu LLM tự tính toán mọi thứ ngay trong câu trả lời. Với các phép tính đơn giản, kết quả có thể đúng. Với chuỗi dữ liệu dài, các điều kiện lọc, quy tắc nghiệp vụ và nhiều bước biến đổi, cách làm đó không tạo được nền tảng đủ chắc để vận hành.
Thiết kế tốt hơn là phân vai. Hệ thống dữ liệu hoặc công cụ tính toán thực hiện phép tính. API truy vấn nguồn có kiểm soát. LLM nhận kết quả đã tính, diễn giải theo yêu cầu, nêu các điểm bất thường và dẫn người dùng về nguồn.
Nghe có vẻ cầu kỳ, nhưng đây là ranh giới giữa “chatbot biết nói về số” và một Workflow phân tích có thể kiểm tra. Khi người dùng hỏi một chỉ số, hệ thống cần trả lời được chỉ số đó lấy từ đâu, lọc theo điều kiện nào, dùng công thức nào, cập nhật đến thời điểm nào. Nếu không trả lời được những câu này, đừng dùng nó làm đầu vào cho quyết định quan trọng.
Tôi không phản đối việc dùng LLM để viết công thức, hỗ trợ tạo truy vấn SQL hoặc đề xuất cách phân tích. Nó rất tiện cho các bước đó. Nhưng mã, truy vấn và kết quả vẫn phải được kiểm tra trong môi trường có kiểm soát. Sự tiện lợi không miễn trừ trách nhiệm kiểm tra.
Không phải bài toán nào cũng cần AI Agent. Nhiều đội đang thấy Agent là xu hướng nên cố nhét nó vào mọi quy trình. Kết quả thường là một hệ thống phức tạp hơn mức cần thiết, nhiều quyền truy cập hơn mức an toàn và khó debug hơn mức chấp nhận được.
Nếu công việc chỉ là tóm tắt báo cáo hoặc trả lời từ chính sách đã phê duyệt, một Workflow đơn giản có bước truy xuất dữ liệu, bước kiểm tra và bước trả lời thường đủ. Agent chỉ đáng cân nhắc khi hệ thống cần chọn công cụ phù hợp giữa nhiều công cụ, xử lý nhiều bước phụ thuộc nhau và có rào chắn rõ ràng cho từng hành động.
Đặc biệt, cần phân biệt Agent có quyền đọc với Agent có quyền ghi. Một Agent đọc dữ liệu, tạo báo cáo nháp và đề xuất việc cần kiểm tra có mức rủi ro khác hoàn toàn với Agent được phép tạo lệnh thanh toán, sửa dữ liệu hoặc gửi thông tin ra ngoài. Quyền ghi cần quy trình phê duyệt rất chặt. Với những quy trình nhạy cảm, tôi nghiêng về mô hình AI đề xuất, con người phê duyệt và hệ thống ghi lại toàn bộ dấu vết xử lý.
Bài viết về AI Agents và cách điều phối đúng có một ý tôi đồng tình: nhiều Agent không tự động làm bài toán tốt hơn. Trong tài chính, thêm Agent thường đồng nghĩa thêm đường đi của dữ liệu, thêm điểm lỗi và thêm việc phải kiểm soát.
Tôi sẽ không triển khai AI phân tích tài chính nếu chưa trả lời được câu hỏi kiểm tra đầu ra. Đây không phải phần trang trí cho slide thuyết trình. Nó là phần quyết định hệ thống có dùng được hay chỉ dừng ở demo.
Trước hết, cần một tập tình huống đại diện cho công việc thật. Nó nên có dữ liệu chuẩn, câu hỏi chuẩn và đáp án hoặc tiêu chí đánh giá do người có chuyên môn xác nhận. Mục đích không phải tìm một điểm benchmark đẹp để quảng cáo. Mục đích là biết hệ thống sai ở đâu: trích sai nguồn, hiểu sai kỳ, tính sai, bỏ sót điều kiện, hay bịa phần giải thích.
Sau đó, xác định điều gì bắt buộc đúng. Có loại lỗi chấp nhận được ở mức câu chữ: diễn đạt chưa gọn, tóm tắt thiếu một ý phụ. Nhưng có loại lỗi không được phép đi qua: gán nhầm số liệu, nhầm đơn vị, tiết lộ dữ liệu, suy đoán về một giao dịch mà không có nguồn, hoặc thực hiện hành động ngoài quyền hạn.
Hệ thống cũng cần khả năng quan sát. Người vận hành phải biết câu hỏi nào được gửi, hệ thống đã dùng tài liệu nào, gọi API nào, kết quả trung gian là gì và phiên bản prompt hay model nào đã tạo đầu ra. Nếu chỉ thấy câu trả lời cuối, bạn gần như không có cách điều tra khi có tranh chấp.
Đây là lý do tôi xem evaluation và observability là hạ tầng, không phải tính năng thêm vào sau. Bài viết AI App Chạy Được Nhưng Chưa Đáng Tin diễn đạt rất đúng tinh thần này: thấy hệ thống làm gì và đo được chất lượng của nó là hai việc cần đi cùng nhau.
AI phân tích tài chính không chỉ là câu chuyện chất lượng câu trả lời. Nó còn là câu chuyện dữ liệu đi đâu, ai nhìn thấy, lưu bao lâu và có thể bị dùng lại hay không. Một file tài chính có thể chứa thông tin khách hàng, giá, lương, công nợ, kế hoạch đầu tư hoặc điều khoản hợp đồng. Sai một lần ở đây không phải lỗi đánh máy.
Trước khi chọn công cụ, đội cần xác định dữ liệu nào được phép đưa vào, dữ liệu nào cần che bớt, ai được truy cập, và yêu cầu nào cần log. Cũng cần xác định ranh giới giữa môi trường thử nghiệm và môi trường vận hành. Đừng lấy dữ liệu thật nhạy cảm làm nhiên liệu mặc định cho một thử nghiệm chưa có quy trình.
Một nguyên tắc đơn giản là cấp quyền tối thiểu cần thiết. Hệ thống trả lời quy định chi phí không cần thấy toàn bộ dữ liệu thanh toán. Hệ thống hỗ trợ phân tích biến động có thể chỉ cần dữ liệu đã tổng hợp nếu mục tiêu không yêu cầu chi tiết giao dịch. Giảm phạm vi dữ liệu không làm AI kém thông minh; nó làm rủi ro thấp hơn.
Tôi sẽ không bắt đầu bằng việc mua một nền tảng lớn hay tuyên bố “chuyển đổi AI”. Tôi sẽ chọn một Workflow lặp lại, gây tốn thời gian nhưng có ranh giới rõ. Chẳng hạn: tóm tắt tài liệu phục vụ rà soát, chuẩn bị câu hỏi cho báo cáo biến động, hoặc tìm chính sách nội bộ từ kho tài liệu đã duyệt.
Hãy viết quy trình hiện tại ra giấy trước. Dữ liệu vào là gì? Ai thực hiện? Mất công ở bước nào? Đầu ra nào được dùng? Ai phê duyệt? Khi đã có bản đồ này, bạn mới biết AI nên đứng ở đâu. Nhiều trường hợp, câu trả lời không phải là “thay cả quy trình”, mà chỉ là “giảm thao tác thủ công ở một bước”.
Sau đó đặt tiêu chuẩn thành công bằng chất lượng công việc, không bằng cảm giác mới lạ. Người dùng có tìm được thông tin nhanh hơn không? Số lượt phải làm lại có giảm không? Đầu ra có dẫn được về nguồn không? Người phụ trách có tin đủ để dùng nó làm bản nháp không? Nếu không trả lời được các câu hỏi đó, dự án đang chạy theo sự hào hứng hơn là giá trị.
Quan điểm của tôi khá bảo thủ ở chỗ này: hãy ưu tiên công cụ làm đội tài chính bớt mệt và kiểm soát tốt hơn, trước khi mơ về hệ thống tự động ra quyết định. Một Workflow nhỏ nhưng có nguồn dữ liệu rõ, kiểm tra được và được người dùng chấp nhận đáng giá hơn một AI Agent hoành tráng không ai dám dùng khi cần chịu trách nhiệm.
AI có thể xử lý một phần công việc lặp lại như đọc, phân loại, tóm tắt, gợi ý câu hỏi và soạn bản nháp. Nhưng phân tích tài chính còn bao gồm việc chọn giả định, hiểu giao dịch, đánh giá ngoại lệ và chịu trách nhiệm cho quyết định. Những phần đó không nên bị giao phó chỉ vì AI viết câu trả lời nghe hợp lý.
Chỉ nên quyết định sau khi hiểu rõ chính sách dữ liệu, quyền truy cập và quy định nội bộ của tổ chức. Với dữ liệu nhạy cảm, cần cân nhắc giảm dữ liệu đưa vào, che thông tin không cần thiết và dùng môi trường có kiểm soát. Sự tiện của thao tác tải file không phải tiêu chí duy nhất.
Yêu cầu hệ thống chỉ ra nguồn dữ liệu, công thức, điều kiện lọc và giả định. Dùng tập tình huống đã được người có chuyên môn kiểm tra để đánh giá. Theo dõi các lỗi thực tế sau khi vận hành. Nếu AI không thể cho thấy đường đi từ dữ liệu đến kết luận, mức độ tin cậy cần rất thấp.
RAG phù hợp khi người dùng cần hỏi đáp từ tài liệu nội bộ như quy trình, chính sách, hợp đồng hoặc tài liệu hướng dẫn. Nó không tự giải quyết bài toán tính toán hay đảm bảo tài liệu nguồn là đúng. Chất lượng phụ thuộc mạnh vào kho tài liệu, cách truy xuất và việc câu trả lời có dẫn về nguồn hay không.
Với các hành động có tác động thực tế như tạo lệnh, sửa dữ liệu hay gửi thông tin nhạy cảm, cần thiết kế quyền hạn, bước phê duyệt và log kiểm toán rất rõ. Trong phần lớn tình huống, mô hình AI đề xuất và con người phê duyệt là lựa chọn thận trọng hơn việc trao quyền tự thực hiện.
Nguồn tham khảo: cuongnguyen.ai.vn
Bài viết là góc nhìn cá nhân của tác giả, mang tính tham khảo — không phải tin tức báo chí.
Đừng bỏ lỡ bài viết tiếp theo. Đăng ký để nhận trong inbox.

Tác giả
Tôi là Cường Nguyễn - Founder của AI Ops Solutions.
Tôi từng là Logistics Operations Manager và đồng sáng lập thương hiệu CATCA - #1 Shopee ngành Pet Care.