Phụ lục A. Bộ câu hỏi trước khi mua hoặc xây EdTech

Phụ lục này không phải checklist để tick cho xong. Nó là một công cụ làm chậm quyết định đúng lúc. Trước khi mua một nền tảng, xây một tính năng, thêm AI vào sản phẩm, triển khai app mới cho giáo viên, hoặc gia hạn một hợp đồng EdTech, tổ chức nên dùng bộ câu hỏi này để buộc lời hứa công nghệ đi qua bốn lớp: vấn đề giáo dục, điều kiện triển khai, quyền của con người, và khả năng rời đi. Nếu một sản phẩm không trả lời được các câu hỏi này, vấn đề không nằm ở việc bộ câu hỏi quá khó. Vấn đề nằm ở chỗ quyết định đang dựa trên cảm giác, demo hoặc áp lực thị trường nhiều hơn là trách nhiệm giáo dục.

Bộ câu hỏi này có thể dùng cho ba loại quyết định. Loại thứ nhất là mua sản phẩm bên ngoài: LMS, app luyện tập, AI tutor, hệ thống assessment, công cụ phụ huynh, learning analytics, credential platform. Loại thứ hai là xây sản phẩm nội bộ hoặc sản phẩm thương mại: tính năng feedback, AI assistant, dashboard, kho học liệu, công cụ quản lý lớp, hệ thống can thiệp. Loại thứ ba là gia hạn hoặc mở rộng một hệ thống đã có. Gia hạn cũng là một quyết định mua mới, chỉ nguy hiểm hơn vì con người đã quen, dữ liệu đã nằm trong hệ thống, và exit cost thường bị che bởi thói quen.

Cách dùng tốt nhất là biến phụ lục này thành một decision memo ngắn. Không cần viết luận văn. Nhưng mỗi nhóm quyết định phải trả lời đủ rõ: vấn đề là gì, bằng chứng nào cho thấy vấn đề có thật, công nghệ giải phần nào, ai được lợi, ai chịu rủi ro, dữ liệu nào bị thu, giáo viên phải làm thêm gì, người học có quyền gì, chi phí thật là gì, khi nào dừng, và nếu sản phẩm biến mất thì tổ chức còn giữ được gì. Một quyết định EdTech trưởng thành không phải quyết định không có rủi ro. Nó là quyết định biết rủi ro nằm ở đâu và có quyền sửa sai.

1. Tóm tắt quyết định trong một trang

Trước khi đi vào phân tích dài, hãy viết một trang tóm tắt. Nếu một quyết định không thể được mô tả rõ trong một trang, thường có hai khả năng: hoặc vấn đề chưa được hiểu, hoặc sản phẩm đang được bán bằng quá nhiều lời hứa cùng lúc.

Tên quyết định: Mua, xây, thử nghiệm, gia hạn hay mở rộng công cụ nào? Nhóm người dùng chính: Người học, giáo viên, phụ huynh, quản trị, đội vận hành, hay nhiều nhóm cùng lúc? Vấn đề cụ thể: Công cụ này giải vấn đề giáo dục/vận hành nào? Quyết định đề xuất: Không dùng, thử nhỏ, triển khai có điều kiện, triển khai rộng, hay gia hạn? Mức rủi ro: Thấp, trung bình, cao, hoặc high-stakes. Dữ liệu bị xử lý: Không có dữ liệu cá nhân, dữ liệu học tập cơ bản, dữ liệu nhạy cảm, dữ liệu trẻ em, dữ liệu đánh giá, hay dữ liệu hành vi. AI có tham gia không: Không; có nhưng low-stakes; có trong feedback; có trong assessment; có trong analytics; có trong quyết định high-risk. Điều kiện thành công: Sau 3-6 tháng, điều gì phải thay đổi để gọi là đáng dùng? Điều kiện dừng: Điều gì xảy ra thì phải dừng, thu hẹp hoặc thiết kế lại?

Một trang tóm tắt này nên được đọc bởi ít nhất bốn nhóm: người quyết định ngân sách, người triển khai, giáo viên/người dùng chính, và người chịu trách nhiệm dữ liệu hoặc bảo vệ người học. Nếu chỉ đội mua sắm và vendor hiểu quyết định, quyết định đó chưa đủ giáo dục.

2. Vấn đề có thật không?

Câu hỏi đầu tiên không phải “sản phẩm này làm được gì?” mà là “vấn đề này có thật không?”. EdTech thường bắt đầu sai vì bị kéo bởi tính năng: có AI, có dashboard, có gamification, có cá nhân hóa, có app phụ huynh, có analytics. Nhưng một tính năng hấp dẫn không chứng minh một vấn đề giáo dục tồn tại. Trước khi mua hoặc xây, hãy mô tả nỗi đau hiện tại bằng ngôn ngữ không công nghệ.

Vấn đề nằm ở học tập, vận hành, tiếp cận, đánh giá, giao tiếp, dữ liệu, chi phí, hay hạ tầng? Ai đang chịu nỗi đau này hằng ngày? Người học đang mất cơ hội gì? Giáo viên đang mất thời gian ở đâu? Phụ huynh đang thiếu thông tin nào? Nhà trường đang mù điểm nào? Có dữ liệu hoặc quan sát nào chứng minh vấn đề, hay chỉ là cảm giác “nên hiện đại hơn”? Nếu không dùng công nghệ, có cách nào giải vấn đề bằng quy trình, lịch, nhân sự, chính sách, tài liệu hoặc đào tạo không?

Cần phân biệt vấn đề gốc và triệu chứng. “Học sinh không hoàn thành bài online” có thể không phải vấn đề thiếu app nhắc việc. Nguyên nhân có thể là bài quá dài, thiếu cấu trúc, mạng yếu, người học không có không gian, giáo viên không phản hồi, bài không gắn điểm, hoặc học sinh không hiểu mục tiêu. “Giáo viên không dùng LMS” có thể không phải vì họ chống công nghệ. Nguyên nhân có thể là LMS rối, nhập liệu trùng, không giảm việc, thiếu thời gian tập huấn, hoặc dữ liệu lớp sai. Nếu công nghệ chỉ đánh bóng triệu chứng, nó có thể làm vấn đề trông có vẻ được quản trị nhưng không được giải.

Câu hỏi quyết định: Nếu bỏ tên sản phẩm và bỏ chữ AI, vấn đề còn đủ quan trọng để giải không?

3. Công nghệ giải đúng nguyên nhân hay chỉ làm vấn đề dễ nhìn hơn?

Một dashboard có thể làm vấn đề hiện ra, nhưng nhìn thấy không phải giải quyết. Một early warning system có thể chỉ ra học sinh vắng nhiều, nhưng nếu không có cố vấn, thời gian gọi phụ huynh, hỗ trợ tài chính, can thiệp học tập hoặc quan hệ tin cậy, cảnh báo chỉ tạo thêm danh sách lo lắng. Một AI feedback có thể sửa câu, nhưng nếu người học không có vòng revision, feedback nhanh không thành học sâu. Một LMS có thể gom bài, nhưng nếu chương trình quá tải, nó chỉ gom sự quá tải vào một nơi.

Hãy viết chuỗi tác động của công cụ theo dạng: công cụ làm gì, ai thay đổi hành vi gì, hành vi đó dẫn đến kết quả nào, điều kiện nào phải có để chuỗi đó xảy ra. Ví dụ: “Công cụ gửi cảnh báo học sinh vắng nhiều” chưa phải theory of change. Một chuỗi đầy đủ hơn là: hệ thống phát hiện vắng liên tục trong 7 ngày, cố vấn nhận danh sách ưu tiên, cố vấn gọi học sinh/phụ huynh trong 48 giờ, trường ghi nhận nguyên nhân, nếu nguyên nhân là khó khăn tài chính thì chuyển sang quỹ hỗ trợ, nếu nguyên nhân là học lực thì gán nhóm học phụ đạo, sau 3 tuần đo lại attendance. Nếu thiếu các bước sau cảnh báo, sản phẩm chỉ làm hệ thống thấy rõ hơn sự bất lực của mình.

Câu hỏi cần trả lời: Công cụ này thay đổi hành vi của ai? Người đó có động lực, thời gian, kỹ năng và quyền để thay đổi không? Nếu người đó không thay đổi, công cụ còn tác dụng gì? Nếu tác dụng phụ thuộc vào giáo viên, đã tính workload chưa? Nếu tác dụng phụ thuộc vào phụ huynh, đã tính bất bình đẳng gia đình chưa? Nếu tác dụng phụ thuộc vào người học tự chủ, đã tính nhóm người học yếu kỹ năng tự học chưa?

Một công nghệ đáng dùng phải giải được ít nhất một nguyên nhân thật hoặc tạo điều kiện để con người giải nguyên nhân thật. Nếu nó chỉ tạo hình ảnh quản trị đẹp hơn, hãy dừng hoặc thu hẹp.

4. Ai được lợi trước, ai chịu rủi ro trước?

Một quyết định EdTech thường có nhiều bên liên quan nhưng lợi ích và rủi ro không chia đều. Lãnh đạo có thể được dashboard, giáo viên chịu nhập liệu. Phụ huynh được thông báo, học sinh chịu giám sát. Vendor được dữ liệu usage, nhà trường chịu lock-in. Người học mạnh được linh hoạt, người học yếu bị bỏ lại trong self-paced learning. Nhà nước được báo cáo quy mô, trường chịu compliance. Vì vậy, phải lập bản đồ lợi ích và rủi ro trước khi triển khai.

Hãy viết từng nhóm: người học, giáo viên, phụ huynh, nhà trường, đội vận hành, vendor, nhà nước hoặc nhà đầu tư nếu có. Với mỗi nhóm, trả lời bốn câu: họ được thêm năng lực gì, họ mất quyền gì, họ phải làm thêm gì, họ có quyền phản hồi hoặc từ chối không. Nếu một nhóm nhận lợi ích còn nhóm khác nhận chi phí, quyết định không nhất thiết sai, nhưng phải được nói rõ và bù đắp. Ví dụ, nếu giáo viên phải dùng dashboard mới để can thiệp sớm, tổ chức phải giảm việc khác, cấp thời gian, đào tạo và quyền bỏ qua cảnh báo sai. Nếu học sinh bị thu dữ liệu để cá nhân hóa, phải có data minimization, minh bạch, quyền sửa lỗi và giới hạn mục đích.

Câu hỏi trung tâm: Công nghệ này làm ai có thêm năng lực, ai mất quyền? Nếu câu trả lời chủ yếu là lãnh đạo/vendor có thêm dữ liệu còn giáo viên/người học mất quyền, hãy xem lại.

5. Người dùng cuối có thật sự là người được thiết kế cho không?

Trong EdTech, người mua, người dùng và người chịu rủi ro thường không phải cùng một người. Nhà trường mua cho giáo viên dùng. Phụ huynh mua cho trẻ học. Nhà nước mua cho trường triển khai. Doanh nghiệp mua cho nhân viên hoàn thành training. Vendor bán cho người có ngân sách, nhưng sản phẩm lại sống hoặc chết trong tay người dùng cuối. Sự lệch này là nguồn của rất nhiều sản phẩm đẹp trong demo nhưng chết trong lớp học.

Hãy hỏi: sản phẩm được tối ưu cho ai trước? Nếu tối ưu cho người mua, giao diện quản trị sẽ đẹp nhưng workflow giáo viên có thể nặng. Nếu tối ưu cho phụ huynh, dashboard có thể làm trẻ bị giám sát quá mức. Nếu tối ưu cho học sinh, sản phẩm có thể vui nhưng không phù hợp với quản trị lớp. Nếu tối ưu cho vendor, sản phẩm có thể tăng engagement nhưng không tăng học tập. Không có sản phẩm nào tối ưu hoàn hảo cho mọi bên, nhưng tổ chức phải biết trade-off.

Bài kiểm tra đơn giản: Cho người dùng cuối làm thử công việc thật trong điều kiện thật. Không phải xem demo. Không phải nghe vendor thao tác. Hãy để giáo viên tạo lớp, giao bài, sửa lỗi, xem dữ liệu, phản hồi học sinh. Hãy để học sinh yếu dùng. Hãy để phụ huynh ít rành công nghệ đọc thông báo. Hãy để đội vận hành import danh sách lớp thật. Nếu sản phẩm chỉ mượt khi người bán điều khiển, chưa đủ.

6. Giá trị học tập là gì?

Không phải mọi EdTech đều phải tăng điểm trực tiếp. Một công cụ vận hành có thể đáng dùng vì giảm thất lạc thông tin. Một công cụ phụ huynh có thể đáng dùng vì tăng phối hợp. Một hệ thống credential có thể đáng dùng vì giúp người học mang bằng chứng đi. Nhưng nếu sản phẩm tự nhận là công cụ học tập, phải nói rõ giá trị học tập.

Giá trị học tập nằm ở đâu: tăng practice, tăng feedback, tăng retrieval, tăng explanation, tăng revision, tăng transfer, tăng accessibility, tăng metacognition, tăng động lực, tăng tương tác với giáo viên, hay tăng khả năng duy trì học tập khi hệ thống gián đoạn? Công cụ đo điều gì để biết giá trị đó xảy ra? Usage không đủ. Time-on-task không đủ. Completion không đủ. Số câu làm không đủ. Cần ít nhất một dấu hiệu gần với học tập: chất lượng bài sửa, tỷ lệ hoàn thành có hiểu, lỗi phổ biến giảm, khả năng giải thích tăng, transfer sang nhiệm vụ mới, hoặc giáo viên xác nhận can thiệp hiệu quả.

Câu hỏi gai góc: Nếu người học dùng công cụ nhiều hơn, ta có chắc họ học tốt hơn không? Nếu không chắc, cần đo thêm gì?

7. Công cụ có làm giáo viên mạnh hơn không?

Một sản phẩm EdTech nghiêm túc phải trả lời câu hỏi về giáo viên. Nó giảm việc nào, thêm việc nào, chuyển việc nào, và việc mới có ý nghĩa không? “Giảm tải” là một trong những lời hứa bị lạm dụng nhất. Một AI có thể tạo bài nhanh nhưng giáo viên mất thời gian sửa lỗi. Một LMS có thể gom bài nhưng tăng click. Một dashboard có thể giúp can thiệp nhưng giáo viên phải đọc thêm biểu đồ. Một app phụ huynh có thể giảm giấy tờ nhưng mở thêm kênh làm giáo viên bị kéo ngoài giờ.

Hãy đo workload trước và sau. Không chỉ hỏi giáo viên có thích không. Hãy quan sát: mất bao lâu để tạo lớp, giao bài, xem kết quả, phản hồi, sửa lỗi, liên hệ phụ huynh, export dữ liệu, xử lý học sinh quên mật khẩu. Hãy hỏi công cụ làm giáo viên có thêm phán đoán hay mất phán đoán. Dashboard cho dữ liệu hành động được hay chỉ tạo áp lực? AI tạo bản nháp kiểm chứng được hay khiến giáo viên thành người sửa máy? Hệ thống có cho giáo viên override, chỉnh nội dung, bỏ qua gợi ý, phản hồi lỗi, và tham gia cải tiến không?

Điều kiện tối thiểu: Nếu công cụ yêu cầu giáo viên đổi hành vi, phải có thời gian học, hỗ trợ, quyền điều chỉnh, và giảm một phần việc khác. Không được thêm công cụ rồi gọi đó là đổi mới.

8. Người học có thêm tự chủ hay chỉ bị quản lý kỹ hơn?

Công nghệ có thể cho người học thêm quyền: học lại, hỏi lại, dùng caption, nhận feedback nhanh, xem tiến độ, luyện tập riêng, mang credential đi. Nhưng công nghệ cũng có thể làm người học bị quản lý kỹ hơn: mọi click thành dữ liệu, mọi lỗi thành cảnh báo, mọi tiến độ thành màu, mọi bài làm thành dấu vết lâu dài, mọi tương tác với AI thành hồ sơ. Vì vậy, phải hỏi tự chủ thật nằm ở đâu.

Người học có biết công cụ dùng để làm gì không? Có hiểu dữ liệu nào được thu không? Có quyền xem tiến độ của mình không? Có quyền sửa lỗi dữ liệu không? Có quyền giải thích hoặc khiếu nại nếu bị gắn cờ không? Có lựa chọn thay thế nếu không có thiết bị, mạng, khả năng ngôn ngữ hoặc điều kiện riêng không? Công cụ có giúp người học phát triển metacognition, hay chỉ khiến họ theo lộ trình máy giao? AI có hỏi lại và yêu cầu giải thích, hay làm hộ?

Câu hỏi quan trọng: Sau khi dùng công cụ, người học có làm được nhiều hơn khi không có công cụ không? Nếu không, công cụ có thể đang tạo phụ thuộc.

9. Công bằng có được thiết kế vào sản phẩm không?

Công bằng không tự chảy ra từ access. Một sản phẩm online có thể mở cho nhiều người nhưng chỉ hiệu quả với người có thiết bị tốt, mạng ổn, không gian yên tĩnh, kỹ năng tự học và phụ huynh hỗ trợ. Một AI tutor giá rẻ có thể giúp người học mạnh tiến nhanh hơn, trong khi người học yếu tin sai hoặc phụ thuộc hơn. Một app phụ huynh có thể giúp gia đình có thời gian theo dõi, nhưng làm gia đình ít nguồn lực bị trách vì không phản hồi.

Hãy hỏi sản phẩm chạy thế nào trên thiết bị cũ, màn hình nhỏ, mạng yếu, dữ liệu di động, offline, low literacy, nhiều ngôn ngữ, người học khuyết tật, người học lo âu, người học thiếu không gian riêng, người học có lịch làm việc, phụ huynh ít rành công nghệ. Có caption, transcript, text-to-speech, keyboard navigation, font dễ đọc, contrast, alt text, export, và hỗ trợ assistive technology không? Có bản ngôn ngữ địa phương hoặc khả năng địa phương hóa không? Có đo nhóm không dùng không, hay chỉ đo người dùng tích cực?

Red flag: Sản phẩm nói “ai cũng có thể dùng” nhưng chưa thử với nhóm dễ bị bỏ lại.

10. Dữ liệu nào bị thu, và có thể dùng ít hơn không?

Mọi quyết định EdTech nghiêm túc phải có data map. Công cụ thu dữ liệu định danh, lớp học, điểm, bài làm, feedback, hành vi click, thời lượng, tương tác, vị trí, thiết bị, âm thanh, hình ảnh, cảm xúc, dữ liệu phụ huynh, dữ liệu khuyết tật, hay dữ liệu tư vấn? Dữ liệu nào bắt buộc, dữ liệu nào tùy chọn, dữ liệu nào chỉ để analytics, dữ liệu nào dùng cho AI? Có thể dùng dữ liệu tổng hợp thay vì dữ liệu cá nhân không? Có thể xử lý cục bộ không? Có thể lưu ngắn hơn không? Có thể không thu dữ liệu nhạy cảm không?

Mỗi trường dữ liệu phải gắn với một mục đích giáo dục hoặc vận hành cụ thể. Nếu mục đích là “cải thiện dịch vụ”, cần nói cụ thể cải thiện gì. Nếu mục đích là “cá nhân hóa”, cần nói cá nhân hóa hành động nào. Nếu mục đích là “nghiên cứu”, cần cơ chế đạo đức, ẩn danh và quyền phù hợp. Nếu mục đích là “huấn luyện AI”, cần cơ sở pháp lý, consent nơi cần, dữ liệu tối thiểu, và quyền từ chối. Dữ liệu trẻ em và dữ liệu học tập không nên là nhiên liệu mặc định cho sản phẩm.

Câu hỏi chặn: Công cụ có thể làm tốt 80% giá trị với 20% dữ liệu không? Nếu có, hãy chọn phương án ít dữ liệu hơn.

11. Quyền riêng tư có nằm trong mặc định không?

Privacy by default nghĩa là trạng thái ban đầu bảo vệ người học, giáo viên và phụ huynh. Không phải mọi thứ mở, người dùng tự tìm settings, phụ huynh tự đọc policy, giáo viên tự đoán điều khoản. Một sản phẩm giáo dục không nên mặc định chia sẻ dữ liệu rộng, bật AI training, lưu vô hạn, gửi notification nhạy cảm, hoặc cho nhiều vai trò xem thông tin không cần thiết.

Hãy kiểm tra: quyền truy cập theo vai trò có rõ không? Giáo viên thấy dữ liệu lớp mình hay toàn trường? Phụ huynh thấy dữ liệu nào? Học sinh thấy gì về bạn học? Admin có log truy cập không? Dữ liệu lưu bao lâu? Xóa tài khoản có xóa dữ liệu không? Có retention schedule không? Có encryption không? Có DPA hoặc điều khoản xử lý dữ liệu không? Có báo sự cố không? Có cấm quảng cáo thương mại trong môi trường học tập không? Có giới hạn secondary use không?

Điều kiện tối thiểu: Không triển khai công cụ xử lý dữ liệu cá nhân của người học nếu chưa rõ mục đích, quyền truy cập, lưu trữ, xóa, chia sẻ, breach response và exit.

12. Nếu có AI, AI giữ vai trò gì?

Không hỏi chung “có AI không?”. Hãy hỏi AI làm job nào: tạo bản nháp, sửa lỗi, phản hồi, chấm điểm, tutor, phân tích rủi ro, tư vấn học tập, support phụ huynh, tóm tắt hồ sơ, đề xuất can thiệp, hay tự động hóa quyết định? Mỗi job có mức rủi ro khác nhau. AI tạo tiêu đề bài học không giống AI gắn cờ gian lận. AI gợi ý bài luyện không giống AI phân luồng học sinh.

Với mỗi AI, cần viết job description: AI được làm gì, không được làm gì, dữ liệu nào được dùng, ai phê duyệt output, khi nào phải nói không biết, khi nào gọi con người, log ở đâu, ai audit, ai chịu trách nhiệm khi sai. AI low-stakes có thể có quy trình nhẹ. AI high-stakes phải có human review, giải thích, audit, quyền khiếu nại và fallback. AI cho trẻ em phải có giới hạn tuổi, nội dung, thời lượng, dữ liệu, quan hệ hóa và escalation.

Câu hỏi chặn: AI có thể ảnh hưởng điểm, phân luồng, kỷ luật, học bổng, wellbeing, hoặc cơ hội học tập không? Nếu có, không được triển khai như tính năng tiện ích bình thường.

13. AI có biết bất định, biết dừng và biết gọi người không?

Một AI giáo dục nguy hiểm là AI luôn có câu trả lời. Trong học tập, sự tự tin giả có thể dạy sai, làm người học phụ thuộc, làm giáo viên mất cảnh giác, hoặc khiến phụ huynh tin một thông điệp tự động quá mức. Vì vậy, sản phẩm AI phải thể hiện bất định. Nó phải biết nói “không đủ dữ liệu”, “cần giáo viên xác nhận”, “đây chỉ là gợi ý”, “vấn đề này vượt phạm vi”, “hãy hỏi người lớn/cố vấn”.

Hãy thử các tình huống xấu: học sinh hỏi cách gian lận, hỏi vấn đề sức khỏe tâm thần, đưa thông tin mâu thuẫn, yêu cầu AI làm hộ bài, nhập dữ liệu nhạy cảm, dùng ngôn ngữ địa phương, viết bài có phong cách khác chuẩn, hoặc yêu cầu phán xét một người học. AI phản ứng thế nào? Nó có escalation không? Nó có ngăn người dùng nhập dữ liệu nhạy cảm không? Nó có lưu hội thoại không? Có cách xóa không? Có incident reporting không?

Điều kiện tối thiểu: AI trong giáo dục phải có khả năng abstain, defer và escalate. Nếu không, chỉ dùng trong phạm vi rất thấp rủi ro.

14. Bằng chứng nào là đủ cho quyết định này?

Không phải mọi quyết định cần RCT. Nhưng mọi quyết định cần bằng chứng phù hợp với rủi ro. Công cụ low-stakes có thể bắt đầu bằng pilot nhỏ, quan sát, dữ liệu workload và phản hồi người dùng. Công cụ ảnh hưởng học tập rộng cần bằng chứng learning value và implementation. Công cụ high-stakes cần bằng chứng mạnh hơn, kiểm tra bias, audit, human review và quyền khiếu nại. Công cụ xử lý dữ liệu nhạy cảm cần bằng chứng giá trị đủ lớn để biện minh rủi ro.

Hãy phân biệt bốn thứ: testimonial, usage data, implementation evidence và learning evidence. Testimonial cho biết có người thích. Usage data cho biết có người dùng. Implementation evidence cho biết công cụ sống được trong điều kiện thật. Learning evidence cho biết học tập hoặc kết quả giáo dục cải thiện. Một sản phẩm có nhiều usage nhưng không có learning evidence vẫn có thể chỉ đang giữ chú ý. Một sản phẩm có learning evidence ở nước khác vẫn cần kiểm tra bối cảnh địa phương.

Câu hỏi quyết định: Bằng chứng này trả lời “hiệu quả với ai, trong điều kiện nào, trong bao lâu, so với cái gì, với chi phí nào” chưa?

15. Pilot có thể thất bại không?

Nếu pilot không thể thất bại, nó không phải pilot. Nó là màn trình diễn. Một pilot tốt phải có giả thuyết, baseline, nhóm người dùng đủ thật, dữ liệu người không dùng, tiêu chí thành công, tiêu chí dừng, thời gian hỗ trợ, và cách đo tác dụng phụ. Không chọn toàn giáo viên giỏi công nghệ và lớp dễ rồi gọi đó là bằng chứng triển khai. Không chỉ đo nhóm dùng tích cực. Không chỉ hỏi “có thích không?”.

Pilot nên trả lời: adoption thật là bao nhiêu, ai không dùng và vì sao, workload thay đổi thế nào, lỗi vận hành nào xuất hiện, học sinh yếu có được lợi không, giáo viên có tin dữ liệu không, phụ huynh có hiểu không, support burden là gì, dữ liệu có sạch không, integration có ổn không, và điều gì hỏng khi mở rộng. Nếu pilot chỉ chứng minh sản phẩm có thể hoạt động trong điều kiện đẹp, chưa đủ để rollout.

Điều kiện dừng nên viết trước: Dừng nếu workload giáo viên tăng quá mức, nếu nhóm yếu bị bỏ lại, nếu dữ liệu sai ảnh hưởng quyết định, nếu AI không kiểm soát được lỗi, nếu phụ huynh/học sinh không hiểu quyền dữ liệu, nếu vendor không đáp ứng export, hoặc nếu không có người chịu trách nhiệm vận hành sau pilot.

16. Tổng chi phí sở hữu là gì?

License chỉ là phần nhìn thấy. Total cost of ownership gồm license, thiết bị, mạng, hosting, tích hợp, migration, training, onboarding, support, data cleanup, security review, legal review, downtime, renewal, customization, accessibility fixes, monitoring, evaluation, incident response, và exit. Nó cũng gồm thời gian giáo viên, thời gian học sinh, thời gian phụ huynh và thời gian đội vận hành.

Hãy hỏi: ai trả chi phí năm đầu, năm hai, năm ba? Giá có tăng không? Có phí theo số học sinh, lớp, tính năng, API, lưu trữ, AI token, export, support premium không? Có cần thiết bị mới không? Có làm tăng screen time không? Có tạo thêm việc cho giáo viên không? Có cần thuê người quản trị không? Nếu vendor tăng giá 30% sau khi dữ liệu đã nằm trong hệ thống, tổ chức có phương án không?

Câu hỏi chặn: Nếu tính cả thời gian giáo viên và exit cost, công cụ còn “rẻ” không?

17. Hạ tầng và tích hợp có đủ thật không?

Một sản phẩm hay nhưng không tích hợp được sẽ trở thành gánh nặng. Hãy kiểm tra identity/SSO, roster, lớp, môn, LMS, SIS, gradebook, content repository, credential, messaging, analytics và export. Sản phẩm hỗ trợ chuẩn nào? Có LTI, OneRoster, Ed-Fi, Open Badges, CSV/JSON export, API có tài liệu, webhook, role-based access, audit log không? Có sandbox để thử tích hợp không? Có conformance certification không? Có rate limit hoặc phí API làm tích hợp vô nghĩa không?

Đừng chấp nhận câu “có API” như câu trả lời. API có tài liệu không? Có đủ dữ liệu không? Có ổn định qua phiên bản không? Có thông báo breaking changes không? Có thể dùng API để rời đi không? Export có metadata không? Có import vào hệ thống khác không? Nếu công cụ giữ dữ liệu học tập nhưng không xuất được theo cấu trúc dùng được, đó là rủi ro quyền.

Bài kiểm tra: Yêu cầu vendor xuất một bộ dữ liệu mẫu gồm user, lớp, nội dung, bài làm, điểm, feedback và metadata. Đưa cho đội kỹ thuật hoặc bên độc lập kiểm tra xem có tái sử dụng được không.

18. Quyền rời đi có thật không?

Quyền rời đi là bài kiểm tra đạo đức của nền tảng. Nếu trường không thể rời mà không mất dữ liệu, nội dung, credential, workflow hoặc lịch sử học tập, nhà trường đang bị giữ bằng khóa cửa. Một vendor tốt không sợ câu hỏi exit. Họ có tài liệu migration, export format rõ, support chuyển đổi, điều khoản xóa dữ liệu, deletion certificate, và không dùng phí egress để trừng phạt người rời đi.

Hãy hỏi: nếu kết thúc hợp đồng, trong bao lâu vendor phải trả dữ liệu? Dữ liệu ở định dạng nào? Có machine-readable không? Có metadata không? Có file đính kèm không? Có credential không? Có audit logs cần thiết không? Nội dung giáo viên tạo thuộc ai? AI-generated artifacts thuộc ai? Prompt, rubric, guardrails, evaluation logs có xuất được không? Dữ liệu có bị giữ để huấn luyện model không? Vendor có xóa bản sao không? Có xác nhận xóa không?

Exit drill: Trước khi triển khai rộng hoặc gia hạn lớn, hãy thử xuất dữ liệu một lớp/nhóm mẫu và kiểm tra khả năng tái sử dụng. Chưa thử restore thì chưa có backup; chưa thử exit thì chưa có quyền rời đi.

19. Sản phẩm có sống nổi sau hype không?

Một sản phẩm EdTech không chỉ cần tốt lúc demo. Nó phải sống được sau tài trợ, sau pilot, sau người champion rời đi, sau khi vendor đổi đội support, sau khi AI API tăng giá, sau khi chính sách thay đổi, sau khi dữ liệu nhiều lên, sau khi giáo viên mới vào. Hãy hỏi sustainability ở ba lớp: tài chính, con người, kỹ thuật.

Tài chính: ai trả tiền dài hạn, giá có dự đoán được không, có ngân sách bảo trì không? Con người: ai owner, ai training người mới, ai hỗ trợ hằng ngày, ai đọc dữ liệu, ai ra quyết định dừng? Kỹ thuật: có cập nhật, bảo mật, backup, monitoring, documentation, versioning, accessibility, support thiết bị cũ, offline/low-bandwidth nếu cần không? Nếu câu trả lời phụ thuộc vào một người nhiệt tình, đó không phải hệ thống bền.

Câu hỏi chặn: Nếu người champion nghỉ việc, sản phẩm có còn sống không?

20. Môi trường chú ý có được bảo vệ không?

EdTech không chỉ dùng thời gian; nó thiết kế chú ý. Notification, streak, leaderboard, badge, gamification, social feed, parent alert, AI companion, dashboard màu đỏ, reminder liên tục đều có thể kéo người học, giáo viên và phụ huynh vào vòng phản ứng. Một sản phẩm giáo dục không nên vay mượn cơ chế giữ chân của mạng xã hội rồi gọi đó là engagement.

Hãy hỏi: công cụ gửi thông báo gì, cho ai, khi nào, có tắt được không, có mặc định tiết chế không? Gamification có hỗ trợ học sâu hay chỉ tăng hoạt động? Leaderboard có làm người yếu xấu hổ không? Parent alert có làm phụ huynh hoảng không? AI có khuyến khích người học quay lại quá mức không? Dashboard có làm giáo viên bị kéo vào canh chỉ số không? Có giới hạn screen time hoặc thiết kế hoạt động offline không?

Nguyên tắc: Engagement không phải học tập. Chỉ giữ các cơ chế chú ý khi chúng phục vụ mục tiêu học và không làm nghèo wellbeing.

21. Quyền khiếu nại và sửa lỗi ở đâu?

Mọi hệ thống đều sai. Dữ liệu lớp sai, điểm sai, AI feedback sai, gắn cờ gian lận sai, cảnh báo rủi ro sai, phụ huynh nhận thông báo sai, credential sai, thuật toán đề xuất sai. Câu hỏi không phải hệ thống có sai không, mà là người bị ảnh hưởng có cách sửa không.

Người học có biết khi nào AI hoặc thuật toán tham gia không? Có thể hỏi lại ai? Có thể yêu cầu human review không? Có thời hạn phản hồi không? Có log để kiểm tra không? Giáo viên có thể sửa dữ liệu sai không? Phụ huynh có kênh phản hồi không? Nếu sản phẩm gắn cờ gian lận, có quy trình bảo vệ phẩm giá người học không? Nếu dashboard nhãn “rủi ro”, nhãn đó có được giải thích, giới hạn và xóa khi không còn đúng không?

Điều kiện tối thiểu: Không dùng hệ thống ảnh hưởng điểm, cơ hội, kỷ luật, phân luồng hoặc wellbeing nếu không có quyền giải thích, human review và khiếu nại.

22. Ai chịu trách nhiệm khi công cụ sai?

Trách nhiệm không thể nằm trong phần mềm. Nếu AI phản hồi sai, ai chịu? Nếu dữ liệu rò rỉ, ai chịu? Nếu dashboard khiến trường can thiệp sai, ai chịu? Nếu vendor đổi model làm output khác, ai chịu? Nếu giáo viên dùng công cụ chưa duyệt, ai chịu? Nếu phụ huynh hiểu nhầm thông báo tự động, ai sửa quan hệ?

Hãy viết trách nhiệm theo vai trò: vendor chịu gì, nhà trường chịu gì, giáo viên chịu gì, đội IT chịu gì, lãnh đạo chịu gì, người phụ trách dữ liệu chịu gì. Đừng để giáo viên là người chịu trách nhiệm cuối cho hệ thống họ không được cấu hình. Đừng để phụ huynh tự gánh rủi ro vì đã tick consent. Đừng để vendor thoát trách nhiệm bằng câu “AI có thể sai” nếu sản phẩm thiết kế khiến người dùng tin quá mức.

Câu hỏi chặn: Người chịu trách nhiệm có quyền, thông tin và thời gian để chịu trách nhiệm thật không?

23. Quyết định cuối: dừng, thử nhỏ, triển khai có điều kiện, hay triển khai rộng?

Sau khi trả lời các câu hỏi, không nên kết luận bằng cảm giác chung. Hãy chọn một trong bốn quyết định.

Dừng: Khi vấn đề không rõ, công nghệ không giải nguyên nhân, dữ liệu quá mức, rủi ro cao hơn giá trị, thiếu quyền khiếu nại, vendor không export, AI không kiểm soát được, hoặc tổ chức chưa có năng lực triển khai. Dừng không phải thất bại. Dừng là một năng lực trưởng thành.

Thử nhỏ: Khi vấn đề có thật, giá trị có khả năng, rủi ro thấp hoặc có thể giới hạn, nhưng bằng chứng/bối cảnh chưa đủ. Pilot phải có failure criteria, nhóm người dùng thật, đo workload, equity, adoption và tác dụng phụ.

Triển khai có điều kiện: Khi giá trị đủ rõ nhưng còn điều kiện cần hoàn thành: training, data cleanup, DPA, accessibility fix, integration, export test, AI guardrails, support plan, hoặc budget vận hành. Không hoàn thành điều kiện thì không mở rộng.

Triển khai rộng hoặc gia hạn: Chỉ khi sản phẩm chứng minh được giá trị trong bối cảnh thật, chi phí thật chấp nhận được, rủi ro được quản, quyền dữ liệu rõ, giáo viên/người học có hỗ trợ, exit được thử, và tổ chức có năng lực duy trì.

24. Mẫu decision memo ngắn

1. Quyết định: Chúng ta đề xuất mua/xây/thử/gia hạn công cụ nào, trong phạm vi nào? 2. Vấn đề: Vấn đề cụ thể là gì, bằng chứng nào cho thấy vấn đề tồn tại? 3. Người dùng và bên chịu rủi ro: Ai dùng, ai trả tiền, ai chịu thêm việc, ai chịu rủi ro dữ liệu? 4. Theory of change: Công cụ làm gì, ai đổi hành vi gì, kết quả nào sẽ thay đổi? 5. Giá trị kỳ vọng: Learning value, operational value, equity value hoặc accessibility value là gì? 6. Dữ liệu: Thu gì, dùng để làm gì, lưu bao lâu, ai xem, có thể dùng ít hơn không? 7. AI nếu có: AI giữ job nào, giới hạn nào, ai duyệt, khi nào escalate, audit thế nào? 8. Triển khai: Training, support, owner, workflow, timeline và failure criteria là gì? 9. Chi phí: License, training, integration, support, workload, renewal và exit cost là gì? 10. Interoperability và exit: Chuẩn nào, export nào, đã thử rời đi chưa? 11. Rủi ro và giảm thiểu: Rủi ro lớn nhất là gì, giảm thế nào, ai chịu trách nhiệm? 12. Quyết định cuối: Dừng, thử nhỏ, triển khai có điều kiện, triển khai rộng/gia hạn. Vì sao?

Decision memo tốt nên ngắn nhưng không mơ hồ. Nếu không thể viết rõ mục 2, đừng mua. Nếu không thể viết rõ mục 6, đừng xử lý dữ liệu người học. Nếu không thể viết rõ mục 8, đừng triển khai. Nếu không thể viết rõ mục 10, đừng ký hợp đồng dài hạn.

25. Các dấu hiệu đỏ

Sản phẩm hứa “cá nhân hóa toàn diện” nhưng không nói rõ dữ liệu và logic gợi ý. Sản phẩm nói “AI thay giáo viên” hoặc “giảm 80% công việc” mà không đo workload thật. Vendor không cho export dữ liệu mẫu trước khi ký. Hợp đồng không nói rõ dữ liệu giáo viên tạo thuộc ai. Công cụ dùng dữ liệu trẻ em để huấn luyện AI mặc định. Dashboard gắn nhãn học sinh rủi ro nhưng không có quy trình hỗ trợ. Pilot chỉ dùng với giáo viên giỏi công nghệ. Sản phẩm cần phụ huynh theo dõi liên tục để có tác dụng. App tăng notification nhưng không có bằng chứng học tập. Công cụ không có accessibility cơ bản. Giá năm sau không rõ. API có nhưng phải trả phí cao để dùng. Vendor nói “đừng lo, chúng tôi xử lý hết” khi hỏi privacy hoặc security.

Một dấu hiệu đỏ đặc biệt là ngôn ngữ quá chắc. Giáo dục hiếm khi chắc. Sản phẩm nào nói chắc chắn tăng kết quả cho mọi người học, mọi bối cảnh, mọi giáo viên, mọi trường, thường đang bán sự an tâm hơn là bằng chứng. Một vendor đáng tin biết nói giới hạn. Một trường đáng tin biết hỏi giới hạn. Một sản phẩm đáng tin có thể mô tả lúc không nên dùng nó.

26. Các dấu hiệu xanh

Sản phẩm mô tả job hẹp và rõ. Vendor nói được trường hợp không nên dùng. Dữ liệu tối thiểu và mục đích rõ. Export dùng được và được thử. Có chuẩn tích hợp. Có accessibility. Có tài liệu cho giáo viên, phụ huynh và người học bằng ngôn ngữ dễ hiểu. AI nếu có được giới hạn vai trò, có human review, có audit, có escalation. Pilot có failure criteria. Dashboard dẫn đến hành động cụ thể, không chỉ hiển thị. Công cụ giảm việc thật hoặc chuyển việc sang hoạt động có ý nghĩa hơn. Người học có quyền xem, hiểu, khiếu nại và không bị nhãn hóa lâu dài. Vendor chấp nhận điều khoản rời đi. Tổ chức có owner và ngân sách duy trì.

Dấu hiệu xanh quan trọng nhất là sau khi bỏ bớt marketing, sản phẩm vẫn có một giá trị nhỏ rõ ràng. Nó không cần hứa cứu giáo dục. Nó chỉ cần làm đúng một việc quan trọng, trong đúng bối cảnh, với chi phí và quyền được nhìn thấy đầy đủ.

Ghi chú nguồn nền cho phụ lục

Phụ lục này tổng hợp từ các lập luận đã triển khai trong toàn quyển, đặc biệt là các chương về bằng chứng, pilot, total cost of ownership, khung quyết định công bằng, AI governance, hạ tầng công và quyền rời đi. Các nguồn nền nên quay lại khi dùng phụ lục trong quyết định thật gồm: UNESCO GEM Report 2023 Technology in education: A tool on whose terms?; World Bank Digital Technologies in Education; Education Endowment Foundation A School’s Guide to Implementation; UNESCO Guidance for generative AI in education and research; NIST AI Risk Management Framework; UNICEF Policy guidance on AI for children; OECD Digital Education Outlook 2023; các chuẩn interoperability như 1EdTech LTI/OneRoster/Open Badges, Ed-Fi Data Standard, W3C Verifiable Credentials; và các khung pháp lý/khái niệm về data portability như GDPR Article 20 và EU Data Act.