Summary

The paragraph

AI is a family of techniques for finding patterns in data. Modern AI does not think; it imitates. It is mostly statistics, scaled up by enormous amounts of computation. It works well where data is plentiful and failure is cheap. It works badly when the data doesn’t match the deployment context, when failure has human costs, or when the system is asked to do something it was never trained for. For Nepal, the most important questions are not whether to adopt AI — it is already here — but where the data comes from, who controls the system, and what happens when it is wrong.

That is the working definition we have been building toward across six chapters. Reread it slowly. Notice that every claim in it is one we have grounded in detail at some point in the course. You have done the work to earn this paragraph.

What you should now know how to do

We have not asked you to write code. We have asked you to develop a way of thinking about AI systems. If the course has worked, you should now be able to:

• Recognise when a problem is or is not an AI problem. A municipality wanting to forecast water demand needs statistics, not deep learning. A delivery company optimising routes needs search algorithms. Calling everything “AI” is how budgets get spent badly.
• Read a probability output correctly. A 95% confidence score is a careful statistical claim, not a verdict. Decide what action to take on that probability separately from the model itself.
• Spot algorithmic bias. Ask what data the system was trained on, and whether that data represents the people it will be used on. If the answer is no, demand better.
• Distinguish capability from deployment. A capability that works in a research lab can be five years from production. Deployment timing depends on data, regulation, and incentives — not just on the algorithm.
• Hold the four sovereignty questions in mind. Where does the model run? Who owns the weights? Who is liable when it fails? What happens if the vendor walks away?

A short list of habits

Three habits that will serve you well from here:

1. Notice the data behind the model. Every time someone shows you an AI output, ask: what data was the model trained on, and how was that data labelled? The answer is the most important fact about the system.

2. Translate probabilities into actions slowly. A model can be honest about uncertainty; a deployment decision often is not. The gap between “the model says 73%” and “we will block this” is where good and bad policy live.

3. Insist on local evaluation. A system that “works in Singapore” has not been shown to work in Sindhupalchok. The burden of proving local fit is on the vendor, not on the user.

Where to go next

This course has built foundations. It has not built capabilities. If you want to go further, here are reasonable next steps depending on what you want to do.

• If you want to deploy AI in your work, start by looking for small AI systems that solve real problems — language identification, spam filtering, OCR on existing documents. Use the framework from this course to evaluate vendors. Refuse to be the customer who pays for a transformer when Naive Bayes would have done.

• If you want to build AI, our forthcoming Building AI course moves from understanding to making. Light Python is recommended. We work with Nepali datasets and the kind of small, useful systems that actually ship.

• If you want to influence AI policy in Nepal, the four implications from Chapter 6 — work, fairness, language, sovereignty — are the working agenda. The vocabulary you now have is enough to participate. The country needs more people in policy meetings who can tell the difference between an honest claim and marketing.

A closing thought

The risk for a country like Nepal is not that AI fails. It is that AI succeeds — for someone else. Systems built elsewhere, deployed here, optimised for someone else’s users, with the value captured somewhere else. That outcome is not inevitable. But the default outcome, without local capacity, is exactly that.

What stops it is people: people who understand the systems well enough to ask the right questions, label the right data, evaluate the right vendors, and build the right things locally. This course has tried to be a small contribution to making more of those people. You — the reader who got to the end — are the contribution. Take it from here.

The next course, Building AI, moves from understanding to making. It will be released soon.