AI Internship Guide for Osmania University Students: Building a Project Demonstration

A good AI project demonstration is a small, working app that takes a real input, returns a useful output, and shows honestly how well it works. For an Osmania University student, the quickest route is to pick one narrow problem, compare two or three models on the same data, and wrap the best one in a simple web app that a reviewer can open from a link. This guide gives you a sample project brief, a model comparison table, a deployable app outline, a 14-day plan and a viva checklist.

What a demonstration needs to prove

A demo is not a notebook full of output cells. A reviewer, whether an internal examiner, an interviewer or a senior, wants to see four things within five minutes.

• The problem is clear. One sentence says who has the problem and what the system predicts or generates.
• The system runs. Someone else can type or upload an input and see a result without installing anything.
• The evidence is honest. You report metrics on data the model has never seen, and you show where it fails.
• You understand it. You can explain why you chose the model, what the data is, and what you would change next.

Everything below is built to produce those four things in a short, fixed time.

Choose a project that fits two weeks

Most weak demos fail at the first step: the problem is too big. “An AI for healthcare” cannot be demonstrated. “Classify a short complaint message into one of five categories” can. Use this filter before you commit.

1. Data exists today. You can download a public dataset or write 300 to 500 labelled examples yourself in a day.
2. One input, one output. Text in, label out. Image in, class out. Numbers in, prediction out.
3. You can judge correctness. You can say whether an answer is right or wrong without a debate.
4. A baseline is easy. A simple model should run in minutes, so you have something to beat.
5. It matters to someone you know. Campus, local language, farming, transport, small shops. A familiar user makes your error analysis sharper.

Sample project brief (illustrative)

The brief below is an illustrative template, not a record of a finished project. No code or tests described here have been run. Copy the structure and replace the content with your own topic.

Project: Student Query Router

Notice the last row. A clear “out of scope” line protects you in a viva: you never have to defend something you did not build.

Data first: the step that decides your result

Most of your quality comes from data, not from the model name. Spend the first three days here.

• Write a labelling guide. Define each class in two lines with two examples and one borderline case. Without this you will label inconsistently.
• Balance the classes. If one class has 70 percent of the rows, a model that always predicts it looks accurate and is useless. Report macro F1, not accuracy alone.
• Remove personal data. Strip names, phone numbers, roll numbers and email addresses before data goes into a public repository.
• Keep the test set sealed. Do not look at it while choosing features or settings. Use the validation set for that.
• Record the source. For any public dataset, note its name, licence and download date in the README.

Model comparison table

Comparing models is what turns a tutorial copy into a project. The table below is a planning template with qualitative expectations, not measured results. Leave the last column blank until you have run each model on your own test set, then fill in real numbers.

How to run the comparison fairly

1. Use the same train, validation and test split for every model.
2. Fix random seeds and write them in the README.
3. Tune each model on the validation set only, with a similar effort for each.
4. Score every model once on the test set.
5. Report macro F1, per-class precision and recall, and a confusion matrix.
6. Add a cost line: seconds to train, milliseconds per prediction, and size on disk.

The best model for your demo is not always the highest scorer. If a transformer beats logistic regression by one point but needs ten times the memory on a free hosting plan, the simpler model may be the better deployment. Say so and show the numbers.

Worked illustrative example: reading the results

Suppose, hypothetically, that your confusion matrix shows the model often mixes “certificate requests” with “exam forms”. This is an invented scenario to show the reasoning, not a real result. Here is how a strong student handles it.

1. Look at the errors. Print the misclassified messages. You might notice that messages containing “bonafide” and “hall ticket” both mention a form and a date.
2. Diagnose. The classes overlap in vocabulary, and your labelling guide did not say what to do with a message that mentions both.
3. Fix the cause. Update the guide with a rule, relabel the affected rows, and add 30 clearer examples of each class.
4. Re-run on the same sealed test set. Record the change in a short table, “before” and “after”, using your real numbers.
5. Write one honest sentence. For example: the two classes still overlap on messages about both topics, so the app shows the top two categories rather than forcing one answer.

That last step is why the app returns the top two alternatives in the brief. Design choices that come from observed errors are exactly what examiners and interviewers like to hear.

Deployable app outline

You do not need a large system. A small web app with a clear structure is enough, and it can run on a free hosting tier. The structure below is a suggested outline for you to adapt.

Folder layout

query-router/
  data/               # cleaned, anonymised samples only
  notebooks/          # exploration and model comparison
  src/
    train.py          # trains and saves the chosen model
    predict.py        # loads the model, returns label + scores
  app.py              # the web interface
  model/              # saved model file
  tests/              # a few input/output checks
  requirements.txt    # pinned library versions
  README.md
  Dockerfile          # optional

Logic of predict.py (illustrative sketch)

This sketch shows the shape of the function. It has not been executed here, so test it in your own environment before relying on it.

def predict(text, model, top_k=2):
    text = text.strip()
    if len(text.split()) < 3:
        return {"error": "Please enter a longer message."}
    probs = model.predict_proba([text])[0]
    ranked = sorted(zip(model.classes_, probs),
                    key=lambda x: x[1], reverse=True)[:top_k]
    return {"top": ranked[0], "alternatives": ranked[1:]}

App components

• Interface: a single text box, a submit button, and a result area showing label, confidence and alternatives. A lightweight Python framework such as Streamlit or Gradio is enough for this.
• Guardrails: reject empty input, cap the length, and show a low-confidence warning below a threshold you chose on the validation set.
• Examples panel: three clickable sample messages so a reviewer sees a result in one click.
• About panel: data source, date, test macro F1, and known limits in plain language.
• Logging: avoid storing user input unless you tell users. For a demo, no logging is the safest default.

Deployment checklist

1. Pin library versions in requirements.txt and run the app from a fresh virtual environment.
2. Keep the saved model small enough for your host’s memory and file limits; check the host’s current limits on its own documentation page.
3. Push code to a public repository with a clear README.
4. Deploy on a free hosting service that supports Python apps. Hugging Face Spaces, Streamlit Community Cloud and Render are common choices; check which one currently offers a free tier.
5. Open the live link on your phone and on a different network to confirm it loads.
6. Record a two-minute screen capture as a backup in case the link sleeps or the venue Wi-Fi fails.

A 14-day build plan

A two-week structure keeps scope honest. If you join the free two-week online internship from CareerSwami, which offers a free offer letter and a free completion certificate after successful completion across 26 tracks, you can map this plan onto its 14 days. It works equally well on your own.

Osmania University and your AI demo: what the published documents say

Osmania University has its own campus and also affiliated colleges, including autonomous ones. Nizam College, for instance, is described as autonomous at undergraduate level, and the College Development Council coordinates autonomous status with the UGC. In practice, a project rule that applies in one college may not apply in another, so the department that teaches your programme is the authority for your demonstration project.

Internship provisions in the published documents are programme-specific. A 2021 CBCS guidelines circular lists summer internship among credits outside the CGPA, and the 2025-26 B.Com (General) structure allows up to 4 summer-internship credits. The 2023 M.Com syllabus splits final project marks into project work, an internship report and a viva. These are older or programme-specific excerpts, so check the current version. They do not mention online or independent AI internships, and nothing here says an outside project such as this one counts for credit.

Students on management programmes can link the demo to their syllabus. The 2024-25 MBA (Technology Management) second-year syllabus has an excerpt mentioning machine learning topics, so a query-routing or classification demo can be described in the vocabulary of that paper. The MBA (Day) 2025-26 syllabus is a single PDF for all four semesters. Check the exact paper titles yourself before citing them in a report.

For showing the project to employers, the Human Capital Development Centre is the university’s nodal body for industry interface and employability, with a placement cell among its wings. The PG College placement cell page says it measures students’ skills against employer expectations. Ask them what a repository link or demo should contain.

Calendars are issued per programme, for example an MCA almanac for 2026-27, so plan your 14 days around your own programme’s dates.

Checks to make before you build the demo

• Find your almanac: open the academic calendar page and locate your programme’s almanac before fixing the 14-day window around exams or vivas.
• Read your syllabus PDF: find your programme and admission-year syllabus and note any internship, project or ML paper title and code.
• Ask about outside work: email your department head asking whether an online AI project can be listed in your internship report or project, and what proof is needed.
• Confirm your college type: check whether your college is constituent, affiliated or autonomous, as autonomous colleges may set their own rules.
• Approach placement staff: contact HCDC or your college’s placement cell about the preferred demo format and portfolio links.
• Clear data use: get written approval before using any student or staff data in the project.

Demo-day checklist

Use this list on the day before your viva, review or interview.

Questions to rehearse for the viva

1. Why did you choose this problem, and who would use it?
2. How did you split the data, and why was the test set kept sealed?
3. Why macro F1 rather than accuracy?
4. What does your baseline score, and why is the final model better or not?
5. What are the most common mistakes, and what causes them?
6. How would the model behave on a message in a language or style it never saw?
7. What could go wrong if someone relied on this system without checking?
8. What would you do with two more weeks?

Write a three-line answer to each, using your own numbers. Say “I do not know, but I would test it by…” when that is the truth. It reads better than a confident guess.

Common mistakes in an AI project demo, and how to avoid them

• Data leakage. Duplicate or near-duplicate messages in both train and test sets inflate scores. Deduplicate before splitting.
• Tuning on the test set. If you peek, your final number is no longer an honest estimate.
• Exposed keys. Never commit API keys. Use the host’s secrets setting.
• Overclaiming. “99 percent accurate” on 60 test rows means little. State the test size beside every metric.
• Unexplained copy. If you adapt public code, credit it in the README and be ready to explain every line.
• No fallback. Free hosts may pause idle apps, so open the link a few minutes before you present.

Presenting it as portfolio evidence

When the work is done, turn it into a few lines you can use anywhere. Keep the claims factual and tied to what you built.

• Résumé line: “Built and deployed a five-class text classifier; compared four models on a held-out test set; macro F1 of X on N examples.” Fill in X and N from your own results.
• Repository pinned on your profile: with a README that has a screenshot, a live link and the comparison table.
• Internship proof: if you complete the internship, keep the certificate with your project link. Describe it as a free online internship completion and nothing more, since it carries no stipend, credit or job promise.

Frequently Asked Questions

How long should an AI demo be when I present it?

Aim for five minutes: 30 seconds on the problem, one minute on data and the model comparison, two minutes of live use with three inputs, and the rest on failures and next steps. Keep the backup video ready for a failed connection.

Do I need a GPU to build this project?

No. Logistic regression and linear SVM models run in seconds on an ordinary laptop. Fine-tuning a small transformer is quicker with a GPU, and free notebook services sometimes provide one, but availability and limits change, so check the service’s current terms.

Is a prompted language model acceptable if I do not train anything?

Yes, as one entry in your comparison, as long as you say clearly that it was not trained by you. Examiners still expect a model you can explain end to end, so keep a trained baseline alongside it.

How much data is enough for a classification demo?

For a narrow five-class task, a few hundred well-labelled examples are enough to show a meaningful comparison, provided each class has a reasonable share. State your dataset size beside every metric, and do not generalise beyond it.

Can I use this project for my college mini-project or final-year project?

That depends on your department. Ask your project coordinator in writing whether an outside internship project can be submitted or referenced, and what proof they need. Do not assume it will be accepted.

Which hosting option is best for the live link?

Pick the one that supports your framework, fits your model size within its memory limit, and has a free tier at the moment you deploy. Test the link on another device and network before you present.

What if my Student Query Router scores poorly in the model comparison?

A low score with a good error analysis is a stronger submission than a high score you cannot explain. Show the baseline, show the failure patterns, describe the data fix you tried, and report the before and after numbers honestly.

Is it safe to use real student messages as data?

Only with permission and with all identifying details removed. If in doubt, write synthetic messages yourself and label the dataset as synthetic in the README. Ask your department what approval is needed before collecting real messages.

Related Artificial Intelligence guides

• AI Internship Prerequisites for RGPV Students: Python, Data Handling and Model Basics
• Writing an AI Internship Report as a KTU Student: Methods, Results and Reflection
• AI Internship Project Selection for Ramaiah Institute of Technology Students
• All Artificial Intelligence internship guides